Johannes Geske — December 13, 2019 Introduction
The purpose of Scrum is to maximize product value by delivering a potentially releasable “done” increment through Sprints. While the Development Team is responsible for delivering the increment, the Product Owner is responsible for maximizing value by deciding about the content and the order of the Product Backlog.
Deciding what’s the most valuable thing to do next can be difficult. The transparency of the Product Backlog is key to facilitating decision making. Outcome Mapping is a powerful technique to enhance Product Backlog transparency.
Follow us through the story of the fictional company Amazing Decisions where Kathryn, Sharon, Bruce and a Development Team learn about outcome mapping.
Amazing Decisions
This is Kathryn. Kathryn is the CEO of?Amazing Decisions, a company developing and selling digital products. She wants to increase revenue from sales. Kathryn has set up a meeting with her direct reports Sharon and Bruce to brainstorm ideas.
10 more minutes into this conversation, Kathryn and Bruce were convinced to give Sharon’s approach a try, and so the group decided to follow her idea.
Sharon went on to explain the structure of the outcome map:
- The goal answers the question, why are we doing this?
- Players are people who can support or hinder us from achieving our goal
- Outcomes describe the changes of the players’ behaviors so that they help us achieve our goal.
- Outputs are the direct results from the activities that we believe we have to produce to create the desired outcomes
Sharon could see from Bruce’s face that he was skeptical about this.
Sharon responded patiently and explained that most organizations set goals and immediately start their activities. And that without understanding how these activities connect to their goals, these organizations risk being busy without achieving their goal.
Hearing this, Bruce seemed convinced for the moment, so he asked Sharon how to start creating an outcome map.
After they defined this player, they went on to look into how this player will have to change their behavior to achieve the company’s goal of increasing revenue.
Here came the tough bit of the process for Sharon and Bruce. This is where they had to think of all the outputs they could do to achieve the outcome, while adding more players. And they also had to think about outputs that would clearly not contribute to the outcome, like Bruce’s first proposal to build widgets 2000 and 5000, as he reluctantly admitted.
Let’s catch up with them after they had been hard at work creating their outcome map to meet their goal.
Sharon was happy to see that she had convinced Bruce, but she felt she had to stop him from rushing things. She explained that not every output would be equally valuable and that some were based on assumptions that they would have to test.
Shortly after that meeting, Bruce and Sharon met with the Development Team to refine the Product Backlog. The Development Team was already familiar with outcome mapping, so Sharon kept her explanation short: She emphasized that outputs are usually just assumptions of value. Like any assumption they need to see if it’s true, and so they should try to find out if building these outputs will actually lead to the outcomes we want.
Sharon, Bruce and the Development Team then went on to refine the outputs by adding details, estimates, assumed value and order. For outputs with higher estimates or riskier assumptions, they defined experiments they would run to test their assumptions and avoid investing time into creating something that has no value.
When their meeting came to an end, a lot of the outputs were “ready” and could be selected for the coming Sprint. That’s when Bruce, who had been actively participating in the meeting, asked about the outputs and outcomes that weren’t discussed.
After Sharon had explained how the Outcome Map was like an iceberg that had the most valuable Product Backlog items at its top and those with the lowest value at the bottom, Bruce was content. He offered to help with Product Backlog refinement and was looking forward to the Sprint Review where they’d be reviewing the increment and discussing what to do next.
Closing
We hope you enjoyed this story of Sharon, Bruce and the Development Team using outcome mapping to enhance the transparency of their Product Backlog. An outcome map makes transparent the relationship between a goal, the players contributing to that goal, their desired behaviors and the outputs built by a Development Team. With that transparency in place, Product Owners, Scrum Teams and their stakeholders can improve their collaboration to maximize product value.
If you find that outcome mapping is a valuable exercise for you, you’ll find more information about outcome mapping including an outcome map template on our website.
Business & Finance Articles on Business 2 Community
(72)
