Envisioning (Planning) Products in Scrum: Chapter 17
Every new product and every product improvement begins as an idea. Envisioning is a product-level planning activity that helps organizations describe the idea and create a rough plan for how to approach its creation. The decision on whether or not to turn the idea into a product happens in portfolio planning, which was the topic of the previous chapter.
Envisioning Products in Scrum: An Overview
Envisioning products in Scrum is a lightweight process. The goal is to move quickly from the guessing stage—where organizations think they know the needs of the customer and the potential solution—to the fast feedback stage. So agile organizations use the envisioning process to produce three key pieces of data:
- A product vision.
- Enough details to understand the customers, features, and high-level solution.
- An idea of how much the product might cost.
With this information, organizations can make a decision about whether to fund the next level of product creation: more detailed development.
Envisioning Products in Scrum: Timing
Envisioning products in Scrum is an ongoing activity, not a one-time event. New or revised ideas about in-process products are also vetted through the envisioning process. As such, after the initial envisioning phase, subsequent envisioning sessions will likely be held to determine whether to proceed with the original vision, pivot to a new vision, or end the project (either by releasing the product as is or terminating the effort).
Envisioning Products in Scrum: Participants
During initial envisioning for a product in Scrum, the only required participant is the product owner. Typically, however, the product owner collaborates with one or more internal stakeholders, specialists in market research, business case development, user-experience design, and systems architecture. The process is shown in the image below. Optional participants and artifacts are indicated by a dashed outline.
Notice that the Scrum team members are optional participants to envisioning. This reflects the reality that, during initial envisioning, a Scrum team might not yet be funded. Once product development is underway, or anytime a full Scrum team is available to lend insight and technical expertise, the Scrum team should be included.
Envisioning Products in Scrum: Process
For a new product, the main input to envisioning products in Scrum would be an idea that has cleared the organization’s strategic filter. For an in-process product, the main input would be a pivoted idea. A pivoted idea in Scrum is an idea that has been updated or revised based on user or customer feedback, funding changes, unpredictable moves by competitors, or other important changes that occur within the complex environment in which ideas must exist.
But these aren’t the only inputs to envisioning products in Scrum. Organizations must also understand the following:
- Planning horizon: How far into the future to consider.
- Completion date for envisioning.
- Quantity and type of resources available to conduct envisioning.
- Confidence threshold: Set of information that the decision-makers need in order to make a go/no-go decision.
Envisioning products in Scrum requires several different activities, each generating an important output, such as the product vision, the initial product backlog, or (optionally) the product roadmap. Organizations should also perform any activities necessary to achieve the targeted confidence threshold in an economically sensible way.
The Product Vision in Scrum
Organizations should create a compelling vision that represents the new product idea. This is not an elaborate, several-hundred page document. The product vision in Scrum is a brief statement of the desired future state that would be achieved by developing and deploying a product. A good vision should be simple to state and provide a coherent direction to the people who are asked to realize it.
An example of a good product vision is Kennedy’s vision to go the the moon: “I believe that this nation should commit itself to achieving the goal before this decade is out of landing a man on the moon and returning him safely to Earth.” In 31 words, Kennedy was able to express an aggressive, unambiguous vision that to be realized, would eventually require the efforts of thousands of collaborating people building many complex systems with hundreds of thousands of interrelated components.
When developing products or services, many visions are expressed in terms of stakeholder value. This can be anything from achieving parity with competition or raising the parity bar, to targeting a new market, to shortening the time to market, to redefining the game by changing market focus.
Popular vision formats, many of which are based on Jim Highsmith’s 2009
- Elevator statement: 30-second to 1-minute quick pitch of the product vision.
- Product datasheet: A 1-page marketing piece.
- Product vision box: Illustrate the box the product might ship in, including 3-4 points to emphasize on the label.
- User conference slides: 2-3 presentation slides that introduce the product at a user conference. Avoid bullet points.
- Press release: Write the ideal 1-page press release describing what is newsworthy about the new product when it becomes available.
- Magazine review: Draft a fictitious magazine review bylined by the solution reviewer in your industry’s most popular trade magazine.
High-Level Product Backlog Creation
The initial product backlog for an envisioned product should be high level. Expressed in user story terminology, that means the product backlog items should be epics—really large stories that align with the product vision and provide the next level of product detail for senior management and the Scrum team.
Product Roadmap Definition
Once they have created an initial product vision and a high-level product backlog, many organizations choose to define a product roadmap—a series of small, frequent, incremental releases for achieving some or all of the product vision.
Product Roadmaps Define Minimum Releasable / Marketable Features or Minimum Viable Products
Each incremental release in the product roadmap should be focused on a small set of minimum releasable features (MRFs) around which the stakeholder community shares a strong group consensus. Minimum releasable features (MRFs) represent the smallest set of must-have features—the features that simply have to be in the release in order to meet customer value and quality expectation. Some people refer to this set of features as the minimum viable product (MVP) or minimum marketable features (MMFs). A full discussion of the topic can be found in the blog, “MVPs, MMFs, and MRFs, Oh My!”
Product roadmaps need release goals
Each release on the product roadmap should have a clearly defined release goal: a release goal communicates the purpose and desired outcome of the release. Release goals are based on any factors the company deems relevant to help define the target set of releases, including the target customers for that particular release, high-level architectural issues, significant marketplace events, and so on.
Remember that the product roadmap is a rough first approximation of one or a few near-term releases. It shouldn’t look too far into the future because too much could change. All product roadmaps should be updated as better information becomes available.
Other Activities When Envisioning Products in Scrum
Envisioning should include any work that those involved agree is relevant to achieving the target confidence threshold. This could include a timeboxed market research effort, quick competitive analysis, or a rough business model.
Economically Sensible Envisioning
Envisioning products in Scrum must be carried out in an economically sensible way. Agile companies understand the risks of overinvesting in envisioning for a product that might never make it through the go/no-go stage, or of creating a wasteful inventory of product-planning artifacts that may have to be reworked or discarded when they begin to acquire validated learning. The following sections detail helpful guidelines for economically sensible envisioning.
Economically Sensible Envisioning Targets a Realistic Confidence Threshold
The confidence threshold is a sort of definition of done for envisioning. The confidence threshold defines the minimum level and type of information that decision makers need to make the next-level go/no-go funding decision. Think of the confidence threshold as the bar that must be cleared before the product is ready for the scrutiny of portfolio planning. The image below describes the economic consequences of setting the confidence threshold bar too high.
Economically Sensible Envisioning Focuses on a Short Horizon
Economically sensible envisioning looks primarily at the must-have features for the first candidate release.
Economically Sensible Envisioning Acts Quickly
Economically sensible envisioning should be fast and efficient. That’s why many envisioning efforts include an expected completion date as one of the inputs. Spending less time envisioning also promotes a sense of urgency for making a product decision. After all, the goal is to begin building something tangible that can be used to validate understandings and assumptions. The time spent envisioning should be included in the calculation of time needed to build the solution, as it has very real impacts on the delivery time and costs involved in delivering the product.
Economically Sensible Envisioning Considers the Cost of Validated Learning
The predictive activities in economically sensible envisioning are chosen based on how much they contribute to the acquisition of validated learning regarding the target customer, the target set of features, or the solution. Activities that generate information based solely on guessing and assumptions are a bad investment. They clutter people’s judgment and lead people to believe they understand the situation better than they actually do. Don’t make important decisions under the illusion of certainty. Invest in validated learning instead.
Economically Sensible Envisioning Favors Incremental/Provisional Funding
Economically sensible envisioning considers an incremental or provisional approach to funding product development. Using incremental funding, organizations fund the first small part of development—only enough to acquire the next level of real-world knowledge regarding their customers, features, or solution approach. They then revisit the funding decision as often as every sprint, knowing they can cancel the project (or pivot to a different solution) at any time. The safety created by incremental funding reduces the scope of envisioning and the time it takes to complete it.
Economically Sensible Envisioning Learns Fast and Pivots (Fails Fast)
Economically sensible envisioning is part of a learn-fast-and-pivot cycle, often referred to as fail fast. Fail fast is the strategy of trying something, getting fast feedback, and then rapidly inspecting and adapting. In the presence of high levels of uncertainty, it is often less expensive to start working on a product and quickly learn whether the product was a good decision. If it isn’t working, the organization can pivot (re-envision the product) or kill it before more money is spent.
Envisioning Products in Scrum: Summary
Envisioning products in Scrum is a product-level planning activity designed to give an idea just enough detail to help an organization make a go/no-go decision on exploring the idea further through incremental development. The next chapter, “Release planning in Scrum: Chapter 18,” will describe how to use the outputs of envisioning in release planning.