Three years ago I wrote about Jeff Patton’s “Story Mapping”. I described this technique as a great tool to help design and develop products (see Fig. 1 below for a good example of a Story Map). Jeff Patton has now written a book about this technique, titled “User Story Mapping”.

Patton is a well-known user experience (‘UX’) specialist. He starts “User Story Mapping” by stating that “story maps are for breaking down big stories as you tell them.” His point is about telling stories instead of concentrating solely on what should be written. Patton subsequently explains about “talk and doc”; this technique helps you to externalise your thinking as you map the different stories.

“User Story Mapping” then goes on to describe the aspects involved in mapping user stories – taking an idea, mapping it and talking about it:

1. Frame your idea – For me, the ability to put structure around your product idea is one of the most important benefits of Patton’s story mapping technique. Patton urges us to focus on “desired outcomes” for a specific group of customers and users (see Fig. 2 below). Once you’ve gone through the exercise of figuring out what to build, for whom and why, it should be much easier to prioritise development work. As Patton explains, the ultimate goal is “to minimise the amount we build.”
2. Breadth over depth –  Patton recommends focusing on the breadth of a story first, before delving into the depth of it. This means starting with mapping big activities first, and then breaking these down into smaller, more detailed stories. I’ve included a good real-life example from the book in Fig. 3 below. After covering breadth, you can then start exploring details and options per individual user story: What are the specific things my target user would do here? What are alternative things they could do? What would make it really cool? What about when things go wrong?
3. The backbone organises the story map – With a story map, one typically starts with a “backbone”, which is formed at the top of the map. One level can be a basic and high level flow of the story. When this first flow gets too long, you can use the row below to summarise some of the stories.
4. Focus on outcomes – For me, the key of “User Story Mapping” is the point that Patton makes about focusing on outcomes instead of features. “Focus on outcomes – what users need to do and see when the system comes out – and slice out releases that will get you those outcomes.” He then goes on to stress that the secret to prioritisation is to prioritise outcomes and not features.
5. Minimum viable product – Paton takes a leaf out of Eric Ries‘ book by talking about what makes a “Minimum Viable Product” (‘MVP’). You can see how you can use story maps to slice out stories to make up an MVP. Patton debunks the myth that MVP stands for “the crappiest product you could possibly release.” By contrast, Patton reminds us that the MVP is “the smallest product release that successfully achieves its desired outcomes.” Also, an MVP is the smallest thing you can create or do to prove or disprove a (risky) assumption.
6. Start by discussing your opportunity – The first story discussion should be about framing the opportunity, suggests Patton. This is very much akin to the “opportunity assessment”, which product guru Marty Cagan introduced a number of years ago. An important part of this initial assessment of the opportunity is to establish whether the problem that you’re looking to solve really exists (see Fig. 5 below).
7. Exposing risk in the story map – For me, being “Lean” is all about managing risk. User story mapping can help you to identify and mitigate risk early on in the product development process. Story maps are a great way to make risks visible (see Fig. 6 below) and serve as a starting point for a conversation about how to best manage risk.
8. How to create a story map? – Chapter 5 of “User Story Mapping” is all about how to go about creating a story map. Patton provides a good overview of the steps involved in creating a story map as part of a collaborative process. I’ve listed these steps in Fig. 7 below.
9. It’s about the conversation! – So you’ve created a story map, so what!? I’ve learned over the last few years that the critical part of creating a user story map is the conversation around it. Getting the right people in the room to create a shared understanding of the user problem(s) to address is a critical first step. The next, but equally important step, is to use the story map is a reference point for conversation and collaboration. Patton provides a very useful “checklist of what to really talk about”, which I’ve included in Fig. 8 below.

Main learning point: User story mapping is a great tool for anyone who wants to create a structure and conversation around a user problem or a product idea. Jeff Patton’s technique makes you take a step back and think through the problem(s) you’re looking to solve. “User Story Mapping” thus provides a very valuable framework to anyone involved in product development.

Fig. 1 – Example of a User Map – Taken from: http://www.barryovereem.com/the-user-story-mapping-game/

Fig. 2 – Frame your idea – Taken from: Jeff Patton – User Story Mapping, pp. 8-11

• What is it?
• Why build it?
• What will happen when you do?
• Type of users?
• Types of activities people would use the product for?

Fig. 3 – “Mimi’s Big Story” – Taken from: Jeff Patton – User Story Mapping, p. 13

At the top of the user story map you’ll see big activities like:

• Signing up
• Changing my service
• Viewing my band stats
• Publicising a show
• Viewing promotions online

“Publicising a show” was a big thing. It broke down into these steps arranged left to right underneath the “Publicising the show” card.

• Start a show promotion
• Review the promo flyer Mimi created for me
• Customise the promo flyer
• Preview the promo flyer I created

Fig. 4 – Anatomy of a User Story Map – Taken from: http://www.slideshare.net/bradswanson/lean-startup-story-mapping-awesome-products-faster

 Fig. 5 – Start by discussing your opportunity – Taken from: Jeff Patton – User Story Mapping, pp. 38

• What is the big idea?
• Who are the customers?
• Who are the users?
• Why would they want it?
• Why are we building it?

Fig. 6 – Adding risk stories to make risk visible – Taken from: http://www.slideshare.net/AgileME/jason-jones-agileme2015

Fig. 7 – Creating a story map – Taken from: Jeff Patton – User Story Mapping, pp. 67 – 77

1. Write out your story a step at a time – Start with user tasks; how do you expect people to use your product or software to achieve their goals?
2. Organise your story – Organise your stories in a left-to-right flow with what you did first on the left, and what you did later on the right. Maps are organised left-to-right using a narrative flow: this is the order in which you’d tell the story.
3. Explore alternative stories – Once you’ve got a basic narrative flow in place, you’d want to consider edge cases, alternatives, exceptions and capture these in stories. In other words: your basic narrative flow forms the “backbone” or a “happy path”, and the alternative stories are in the “body” of a story map.
4. Distill your map to a backbone –  At this stage, your user story map is likely to look pretty wide and expansive. This is a good point to take a step back and identify clusters of stories that go together. Creating a backbone of your story map is about grouping stories. Patton refers to these groupings as “activities”. These activities aggregate tasks directed at a common goal. Activities and high-level tasks form the backbone of a story map.
5. Slice out tasks that help you reach a specific outcome – This is the bit where you focus on a specific outcome and where you extract those tasks and related details relevant to the outcome.

Fig. 8 – A checklist of what to really talk about – Taken from: Jeff Patton – User Story Mapping, pp. 104 – 107

• Really talk about who – Don’t just talk about “the user.” Be specific. Talk about which user you mean.
• Really talk about what – Start the user stories with user tasks – the things that people want to do with my product.
• Really talk about why – Talk about why the specific user cares. Talk about why other users care. Talk about why the user’s company cares. Talk about why business stakeholders care.
• Talk about what’s going on outside the software – Talk about where people using your product are when they use it. Talk about when they’d use the product, and how often.
• Talk about what goes wrong –  What happens when things go wrong? What happens when the system is down? How else could users accomplish this? How do they meet their needs today?
• Talk about questions and assumptions – Take time to question your assumptions. Do you really understand your users? Is this really what they want? Do they really have these problems? Also question your technical assumptions. What underlying systems do we rely on? Do they really work the way we think? Are there any technical risks we need to consider?
• Talk about better solutions – The really big win comes when those in a story conversation discard some original assumptions about what the solution should be, go back to the problem they’re trying to solve, and then together arrive at a solution that’s more effective and economical to build.
• Talk about how – Talk about the “how” as well as about the “what”. Patton explains the risk of people assuming that a particular solution or the way it’s implemented is a “requirement.” Without explicitly talking about “how”, it’s difficult to think about the cost of the solution. Because, if a solution is too expensive, then it may not be a good option.
• Talk about how long – Ultimately, we need to make some decisions to go forward with building something or not. And it’s tough to make this sort of buying decision without a price tag. For software, that usually means how long it’ll take to write the code.