Outcomes over Outputs

Introduction

The purpose of Agility is to maximize value and managing risks. Deciding what's the most valuable thing to do in order to optimize value and manage risks can be difficult. The transparency about options and opportunities is key to facilitating decision making. Outcome Mapping is a powerful technique to enhance that transparency.

Follow us through the story of the fictional company Amazing Decisions where Kathryn, Sharon, Bruce and a Scrum 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.

Bruce, the VP of Sales wants to produce new widgets to increase revenue. Flashier than the rest of the product range and bigger too.

Sharon, the Product Owner isn’t convinced that more widgets will lead to more revenue. Instead, she suggests to take a step back and understand which customer behavior would lead to more revenue and what the organization would have to do to encourage this behavior.

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.

Let’s pause the story for a moment and have a look at what has happened here: Bruce’s idea is a typical example of producing outputs. Build another thing, produce more, you know the language. Sharon suggested to focus on encouraging customer behavior that would lead to their goal. And that’s the definition of an outcome:

An outcome is a change in behavior that leads to a goal.

Focusing on outcomes is more likely to achieve goals than producing more outputs.

Now, let’s see how the story continues:

Sharon invites Bruce in for another meeting and introduces him to outcome mapping. She had a whiteboard ready showing the basic structure of an outcome map.

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 valuable outputs they could produce to create the intended outcome, while adding more players. And they also had to think about all the 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 Scrum Team to refine the Product Backlog. The Scrum 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.

They 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 collaborating on what to do next.

Closing

We hope you enjoyed this story of Sharon, Bruce and the Scrum 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 (outcomes) and the outputs created by a Scrum 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.

Download Outcomes Mapping Template