This chapter is from the book
This chapter is from the book
This chapter is from the book
Measuring Value
Scrum Teams can measure the value they deliver in a variety of ways, and different kinds of value will need to be measured in different ways, ranging from very general about the product as a whole to highly specific about certain PBIs. In reality, you will probably need all of the following kinds of measures at different times:
General measures of customer happiness:
Net Promoter Score
Revenue or profitability per customer
Repeat customer business
Reduction in total cost of ownership
Improved conversion rates
Growth in number of customers or users
Customer referrals
Achievement of business goals:
Market share
Aggregate revenue or profit
Cost to obtain a new customer
Reduction in cycle time, reductions in inventory on hand, cost savings, or increases in market share
Specific measures of customer results:
Time saved for the customer to achieve a goal
Frequency of feature usage
Duration of feature usage
Number of customers or users using a feature
Transaction completion/abandon rates
Focusing PBIs on User Outcomes
Understanding user needs and desires is key to understanding what is valuable and why. Scrum Teams can apply a number of techniques to understand users better. In particular, two techniques often combined to help Scrum Teams better understand and focus on users are personas/outcomes and User Stories.
Personas and Outcomes
A persona is a fictional character created to represent a user or customer type that might use a product in a similar way. Personas are often created through market research data and customer interviews. They bring the person to life (so to speak) by painting a picture with information related to demographics, lifestyle, goals, and reasons for using the product. Using personas helps the Scrum Team achieve focus by helping them get very specific about who they are targeting with a particular PBI.
An outcome is some condition or goal that a person matching the persona would like to achieve. Understanding these goals helps a Scrum Team achieve focus by clearly articulating what the user or customer would like to achieve.
Using personas and outcomes has the following principal benefits:
Help the people building the products empathize more with the users and their needs
Help identify user pain points and creative solutions
Help create focus while still being able to see the whole
Personas and outcomes are antidotes to features that don’t have clear objectives or a clear target audience. Personas also help avoid vague discussions about “the user,” because no product has a single homogenous kind of user; instead, people use the same product in very different ways to achieve very different outcomes.
IN PRACTICE: USING IMPACT MAPS TO GAIN BETTER PRODUCT INSIGHTS
Impact mapping can be a useful technique for connecting PBIs back to the goals they are intended to meet.9 You can use a modified impact map to connect the business goal you are trying to achieve to the personas that you will serve, the outcomes you hope to help them achieve, the impacts to your organization if you meet that outcome, and the PBIs that you will deliver in the product to achieve those outcomes (see Figure 4-2).
)
Figure 4-2 An extended impact map helps connect PBIs back to goals
In the example in Figure 4-2, the organization—a company that is entering the ride-sharing service market—would like to increase the number of new customers by 20 percent. To do so, it needs to appeal to many different kinds of potential riders, each represented by a different persona. Each persona has different outcomes that it would like to achieve. The company believes that by satisfying specific outcomes, it will achieve certain impacts, or results for the company, and it believes that delivering certain PBIs will help the company do that.
Impact maps can be used in a variety of ways. In the context of Product Backlog refinement, they help the Scrum Team think about how each PBI will provide some outcome. Impact maps also help the Product Owner envision who the product serves, what those different kinds of users or stakeholders would like to achieve by using the product, and how the organization will benefit from helping customers achieve specific outcomes.
IN PRACTICE: EXPRESSING PBIS AS HYPOTHESES OR EXPERIMENTS
Hypothesis-Driven Development (HDD) is a way of expressing PBIs in a way that makes the persona, outcome, measurement, and expected result explicit.10 The discipline of HDD helps Scrum Teams to frame hypotheses and experiments and to be mindful about how they will know whether a hypothesis (or assumption) is true. This encourages everyone to think about not only what they are trying to accomplish, but also how they will measure it.11 Figure 4-3 provides an example of one way to express a hypothesis.
){kind=link}
Figure 4-3 Explicitly expressing hypotheses can help teams uncover unstated assumptions.
User Stories
User Stories are both widely used and widely misused. Their original intent was to serve as a placeholder or token for a conversation about how someone would use the product to achieve some outcome. When they stray from that reminder to have a conversation and become a format for documenting PBIs, they can become utter nonsense, particularly when used to express technical requirements or constraints. To keep this from happening, focus on the 3 Cs of User Stories:12
The Card, which is simply a reminder to have Conversations. It should have a simple, minimal format that fits on an index card (or a sticky note) and may consist of nothing more than “Talk to Mary about how accounts are settled at the end of a billing period.”
The Conversation, which is the actual discussion about the topic mentioned on the card.
The Confirmation, which are the actual tests that prove it works.13
Improving Value Delivered During the Sprint
As the Development Team works on PBIs during a Sprint, their understanding of the value that the PBIs will deliver continues to improve as they learn more, through conversations, through stakeholder feedback, and even from real customers or users if the team is releasing a product during the Sprint. (Yes, this is possible!)14 A PBI is never “locked down” or “finalized” until it is actually “Done.” This includes the details of both what is being built and how it is being built. If members of a Development Team are collaborating with one another, as well as with the Product Owner, they can constantly ask questions related to value and let this drive their decision-making process. For example:
A Scrum Team chooses to split a PBI to focus on the most valuable acceptance criteria for the user functionality required now, which allows the lower-value piece to be reprioritized at a later time based on a consideration of other desired functions.
When seeing a new capability implemented in the product, the Product Owner provides guidance on how to make it more prominent to the target users.
The Development Team sees alternative ways to increase user conversion, which is the stated value of the PBI they are building. They bring these options to the Product Owner, and they negotiate a change to the scope to better meet the business need while still delivering a “Done” Increment in the Sprint.