What is Value?

The term value is used many times in the Scrum Guide. The first time this term is used is in the definition of Scrum: “delivering products of the highest possible value.” It is an interesting experiment to ask people how they define “value.” It is actually difficult to define what value means without using the words “value” or “valuable.” Value is, ultimately, determined by customer experiences.

These questions can help you determine whether you are delivering value:

• Are your customers happy? Do you help them achieve outcomes that they find important?

• Is that happiness reflected in ways that can be profitably monetized?

• Are you adding or shedding customers?

• How quickly can you deliver a new idea to a customer and measure the result?

• Are your employees happy?

Not-for-profit and social enterprises don’t have concerns about profitably monetizing customer outcomes. Even so, they are still concerned with customer outcomes—although they may use names like “citizens” or “clients” instead of “customers.” Some for-profit enterprises are also mission-driven, but missions can be described in terms of achieving a set of outcomes for a group of people, as in the following examples:

• Increasing local employment

• Improving the well-being of a community

• Reducing negative ecological or environmental impacts

Noted management consultant, educator, and author Peter Drucker observed, “If you can’t measure it, you can’t improve it.” The same is true of value: Producing and delivering “Done” Product Increments is not enough; you have to measure the value you are delivering to improve it.

Delivering Faster Is a Good Start, But Not Enough

While many organizations turn to Scrum to “deliver faster,” once they start delivering to customers and measuring the results, they discover that the real benefit of Scrum is getting feedback sooner to drive faster improvement. In fact, if faster delivery alone could solve the problems that organizations face in meeting customer needs, a traditional approach with many very small releases would suffice.

The problem is that, to paraphrase John Wanamaker, more than half of our ideas deliver no value; we just don’t know which half.¹ To improve your ability to deliver value, you have to not only improve the speed at which you deliver value, but also measure what you deliver to determine its value, and you must use that feedback to improve the value you deliver in the next release.

1. John Wanamaker (1838–1922), a wealthy department store owner, famously observed that “Half the money I spend on advertising is wasted; the trouble is, I don’t know which half.”

Studies have shown that 65 percent of features are rarely or never used (see Figure 4-1).² In a similar vein, a 2017 article in the Harvard Business Review stated that “the vast majority of [new ideas] fail in experiments, and even experts often misjudge which ones will pay off. At Google and Bing, only about 10% to 20% of experiments generate positive results. At Microsoft as a whole, one-third prove effective, one-third have neutral results, and one-third have negative results.”³

2. The Professional Product Owner: Leveraging Scrum as a Competitive Advantage by Don McGreal and Ralph Jocham (Addison-Wesley, 2018), part of the Professional Scrum Series from Scrum.org.

3. https://hbr.org/2017/09/the-surprising-power-of-online-experiments

Value is easy to understand when measured in terms of revenue, income, and direct costs, but not all value is monetary in nature. Market share growth rate, diversity of the customer base, customer satisfaction, employee satisfaction, and employee turnover rate are also important measures of value. Likewise, ease of use and ease of product adoption can be important measures that inform product improvements.

Product Value and the Scrum Team

In Scrum, the Product Owner is accountable for maximizing the outcomes that the product will deliver to customers, thereby maximizing the value realized by the organization.

This focus on value and outcomes represents a change for organizations in which output has historically been the measure of success. Output measures things that are produced or consumed, such as features delivered or story points. Output is easy to measure, but it is of only secondary importance: The number of features delivered is irrelevant if none of those features improves the lives or capabilities of the customer. Features delivered matters only in consideration of profitability or time-to-market, but if they produced nothing of value then they are simply waste.

The Scrum Team determines its process within the Scrum Framework. This process includes defining value, delivering value, and measuring value. Although the Product Owner remains accountable, it is likely that a Product Owner needs help. The Product Owner needs input from stakeholders, including customers, users, and Development Team members. The Product Owner also depends on the Development Team to actually deliver value, so it’s important that those team members understand the outcomes that customers seek to better inform decisions.⁴

4. For a much deeper dive into defining products and how to better understand what customers will find valuable, we recommend Scrum.org’s Professional Scrum Product Owner class: https://www.scrum.org/courses/professional-scrum-product-owner-training. If you can’t make it to a class, or even if you can, we also recommend The Professional Scrum Product Owner by McGreal and Jocham, part of Scrum.org’s Professional Scrum Series.

The Product Backlog creates transparency into the relative importance of the work that the Product Owner believes will maximize value delivered. When it’s used most effectively, it forms the foundation for a dialogue with the rest of the Scrum Team as well as stakeholders, about what is valuable.

Using the Product Vision to Enliven Team Purpose, Focus, and Identity

The Product Vision expresses the raison d’etre of the product—who it is for, and what it hopes to do for them. It is important when defining and funding the product, but it also has value in bringing purpose and focus to the Scrum Team and helping them form their identity. Returning to this vision periodically is a useful way to remind everyone on the team why the team exists.⁵ Various related techniques help the team shape and reinforce their identity:

5. For more information on creating a strong product vision, see The Professional Product Owner: Leveraging Scrum as a Competitive Advantage by McGreal and Jocham.

• Product value. A clear understanding of value helps a team understand the why behind their work and how to validate whether their work is contributing value. Knowing the value in a tangible way (e.g., revenue, market share, customer satisfaction) goes a long way toward instilling a sense of purpose.

• Personas. Personas help a team understand users and customers better, so as to develop empathy for them. This ultimately helps team members see the purpose in their work and create better solutions. Some teams post their persona descriptions around their work environment as a continual reminder of the people they are working to help.⁶

  6. For more information on personas, see http://gamestorming.com/empathy-mapping/ and https://www.romanpichler.com/blog/10-tips-agile-personas/.

• Product Roadmap. A Product Roadmap is a visual representation of the high-level plan intended to help a team see the direction of the product over time. The more a roadmap focuses on business objectives and business value, the more it provides a solid purpose.

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.⁹ 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).

9. For a description of a useful extension of impact mapping, see https://www.scrum.org/resources/blog/extending-impact-mapping-gain-better-product-insights.

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.¹⁰ 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.¹¹ Figure 4-3 provides an example of one way to express a hypothesis.

10. Scrum.org’s Professional Scrum with User Experience Course (https://www.scrum.org/courses/professional-scrum-user-experience-training) teaches how to integrate modern UX practices with Scrum, based on the book Lean UX by Jeff Gothelf and Josh Seiden (O’Reilly Media, 2016).

11. For more on Scrum and HDD, see https://www.scrum.org/resources/blog/scrum-and-hypothesis-driven-development.

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. https://www.agilealliance.org/glossary/user-stories/

• 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. If you want to apply User Stories as an effective Product Backlog refinement technique, we recommend Mike Cohn’s book User Stories Applied (Addison-Wesley Professional, 2004).

In Practice: Common Product Backlog Item Pitfalls

Regardless of the format that your PBIs take (personas and outcomes, User Stories, or something else), beware of these common traps:

1. Assuming that PBIs must follow a set format. The commonly used format for User Stories is not the original format, nor is it required. It may be helpful for your Scrum Team to use a format, but they don’t have to fight to fit a PBI into that format. Write what makes sense. After all, the Card is just a reminder to have a Conversation.

2. Not being clear on the user or customer the PBI benefits. If you are writing over and over again, “As a user” at the beginning of a User Story, you are not helping create focus and understanding of the user for whom you are designing a feature or function. As noted in #1, you don’t have to always use this format, but you should have a shared understanding of the users and customers for your product.

3. Not clarifying the value. Often PBIs will state a desired feature, function, or capability, but precisely why that item is desired is not clear. When there isn’t a shared understanding of why you are building something, it is possible that alternative solutions to the problem will not be discussed. This misses an opportunity to maximize value.

4. Treating the PBI as a contract. The Product Backlog is not just the “agile version” of a traditional software requirements document. PBIs are open to change. Consider the User Story technique: It is meant to represent a customer’s needs, not just document them. User Stories are to be elaborated, even during the work of building it.

5. Including implementation details. PBIs should be focused on the “what” rather than the “how.” If you make implementation decisions too early, you may limit your options. You may also create waste by detailing things that are likely to change when implementation actually occurs.

Inspecting and Adapting Based on Feedback

Once you’ve released the product or demonstrated the product to stakeholders, you will have empirical data that you can use to confirm (or reject) your hypotheses. One data point in time usually doesn’t tell you much, but trends over time will show you whether you are getting better or worse in a particular dimension. And, remember, you may need different measures to really understand what is going on.

For example, you might have very happy customers who love your product, but no measures of their happiness will tell you why people don’t buy your product. If you want to expand your market share, you will need to measure more than the current value delivered by the product—that is, you will also need to understand which factors prevent you from realizing the full market potential of your product.¹⁵

15. Scrum.org has developed a framework for understanding how to measure value and improve your ability to deliver value called Evidence-Based Management. The two dimensions of value are Current Value, referring to the value realized by current customers of your product, and Unrealized Value, meaning the potential value that you could deliver to all potential customers, but do not deliver today. For more information, see https://www.scrum.org/resources/evidence-based-management.

As you are analyzing the value trends, consider what changes you released and when and how they may have impacted value. Consider what factors are beyond your control (e.g., a big decline in the stock market could impact users’ decisions even though you’ve implemented new features you expected to increase sales).

Summary

Scrum is not designed to help you build and release more “stuff.” Instead, Scrum helps you maximize the value you create for your customers, and therefore for your organization, by frequently delivering a product, measuring the results, and then learning and adapting so as to wring more value out of the product.

In this chapter, we explored how empiricism, an agile mindset, and teamwork guide you in fiercely tackling difficult product value questions. You must have transparency into value, and you must engage in frequent enough inspections of the actual value realized that you can keep moving in the best direction. Just like the complexity and unpredictability inherent in building a releasable product, figuring out what to build entails some complexity and unpredictability. Scrum provides the minimal level of empiricism, and the Scrum Team needs to determine their process within the Scrum Framework. This process includes how you enable value emergence, measure actual value, and adapt to new information and the changing environment.

The Product Owner is the single person accountable for optimizing value. An empirical Product Owner will engage and empower others to support them in achieving this goal. A strong Product Owner will foster a product mindset across the organization and paint the bigger picture, creating alignment within the Development Team and among stakeholders on the direction of the product and how value is defined. The Product Owner works collaboratively with the Development Team and stakeholders to enable value emergence iteratively and incrementally, guided by the learning from measuring actual value.

Call to Action

Consider these questions with your team:

• How well is the Product Vision understood by the Development Team and stakeholders?

• Where do you need more transparency into desired outcomes and value assumptions?

• What value measures would help you make more informed decisions about what is in the Product Backlog and its order? How frequently would you need to inspect those data?

• How does the Development Team collaborate with the Product Owner or relevant stakeholders during the Sprint?

• How much feedback and new insights come out of the Sprint Review or other collaborative sessions with stakeholders?

• Do stakeholders focus on value delivery as the key measure of success? What conversations can you have to help shift the focus in the right direction?

• What challenges are hurting the most right now? Identify one or two experiments to help improve understanding and measurement of value. For each experiment, be sure to identify the desired impacts and how you will measure them.