User Story Mapping: Discover the Whole Story, Build the Right Product

by Jeff Patton

It’s the most important concept to building good story maps—not to mention writing and telling good stories.

User tasks are the basic building blocks of a story map.

Keep that in mind when you’re thinking about people using your software. They may have different goals when using it. They may use it in different contexts that force them to take into account other people or things.

Tasks are like rocks. If you take a big rock and hit it with a hammer, it’ll break into a bunch of smaller ones. Those smaller rocks are still rocks. It’s the same thing with tasks.

Alistair uses an altitude metaphor where sea level is in the middle, and everything else is either above or below sea level. A sea-level task is one we’d expect to complete before intentionally stopping to do something else. Did you write “Take a shower” in your list of tasks? That’s a sea-level task because you don’t get halfway through your shower and think, Man, this shower is dragging on. I think I’ll grab a cup of coffee and finish this shower later. Alistair calls these functional-level tasks and annotates them with a little ocean wave. But I’ll just call them tasks.

If you haven’t done this already, organize your tasks in a left-to-right flow with what you did first on the left, and what you did later on the right.

I’ll call this left-to-right order the narrative flow, which is a fancy way of saying “storytelling order.”

Maps are organized left-to-right using a narrative flow: the order in which you’d tell the story.

You can tell the typical day story, the fabulous day story, and the story that has an emergency or two—all by pointing at different stickies as you talk through it from left to right.

You might say, “I usually do this, but sometimes I do this” or “I do this, or this, and then this.” (I’m expecting you to fill in the word this with what you actually do, because I can’t see what you’re pointing at from here.)

These sticky notes with a higher goal-level task are called activities. Activities organize a bunch of tasks done by similar people at similar times in order to reach a particular goal.

The row of stickies is the backbone of the map. If you’ve got a map with lots of stickies in it and you wanted to share it, a good way to start is by telling a high-level story. Just read the backbone of the map, with the “…and then they…” conjunction between each activity.

Tasks are short verb phrases that describe what people do. Tasks have different goal levels. Tasks in a map are arranged in a left-to-right narrative flow.

No matter what else we cut out, we have to wake up, get dressed, and drive to work,” observed one participant, with another quickly piping up, “Unless you are working from home!”

Soon after this exercise, story maps became our preferred way to communicate an experience, prioritize user stories, and schedule iterations and releases. It had entered the company’s vernacular and the development culture, and continues through the present day. One lesson I learned, having run this same exercise now for multiple teams in our organization, is to use an icebreaker to prime the mindset of the participants. Start the session by having each person write just one thing he or she did between waking up and getting to work. Then ask each person to answer the question: “Why did you take that action?” I found that this starts a background mental thread

that shows up in later planning sessions: “What is the value of this user story? Why ...

But the map you created is a map about the way you do things now—this morning, as a matter of fact. And, as it turns out, the concepts are the same in both. So be relieved I haven’t wasted your time.

Lots of people in the user experience community have been building these for years to better understand their users. Sometimes they’re called journey maps, but they’re the same basic idea.

From this simple storytelling and mapping activity, we all built shared understanding of how they worked now. It was from here that we could begin to translate this map into the things they’d need to do in the software we’d create later.

If you’re a software professional, it may take you a while to stop talking about features and screens, and to start writing short verb phrases that say what people are really trying to do. Keep practicing. You’ll get it.

This will be really hard if you don’t know exactly who your user is, what she’s trying to accomplish, or how she goes about it. Sadly, trying to build a map in this situation will just point out what you don’t know. If that’s where you are, then you’ll need to learn more about people and what they do. Better yet, work with them directly to create a map.

While I know there are lots of right ways to build up and use a story map, I have found that the following six-step process works well for me: Frame the problem. Who is it for, and why are we building it? Map the big picture. Focus on breadth, not depth. Go a mile wide and an inch deep (or a kilometer

wide and a centimeter deep, for my friends in the rest of the world). If you don’t have a clear solution in mind, or even if you think you do, try mapping the world as it is today, including pains and joys your users have.

Explore. Go deep and talk about other types of users and people, how else they might do things, and the kinds of things that can (and likely will) go wrong. For extra credit, sketch, prototype, test, and refin...

Slice out a release strategy. Remember: there’s always too much to build. Focus on what you’re trying to achieve for your business, and on the people your product will serve. Slice away what’s not needed to reveal minimum solutions that both delight people and help your organization reach its goals. Slice out a learning strategy. You may have identified what you think is a minimum viable solution, but remember that it’s a hypothesis until you prove otherwise. Use the map and discussion to help you find your biggest risks. Slice the map into even smaller minimum viable product experiments that you can place in front of a subset of your users to l...

minimum viable solution into the parts you’d like to build earlier and later. Focus on building things early that help you learn to spot techni...

Building a map helps you see the big picture, to see the forest for the trees. That’s one of the biggest benefits of story mapping. But if you’re the one responsible for building the forest, you’ll need to do it one tree at a time. You’ve already learned the two most important things that make stories work:

Use storytelling with words and pictures to build shared understanding. Don’t just talk about what to build: talk about who will use it and why so you can minimize output and maximize outcome.

Keep these things in mind, and everything will fall into place as you go forward. It’s time we talked about some of the tactics for using stories “tree by tree,” because a lot can go wrong, and there are ...

It seemed to be a simple yet powerful method to turn a product vision into a backlog, and understand what we were going to develop, for whom, and why. So we decided to give it a try.

When a team first uses user story mapping, we recommend the involvement of an experienced coach. The coach sets up a meeting with the requestor and discusses the workshop goals, whom to invite, agenda, relevant inputs, and so forth. Typically, we do a facilitated one-day workshop with the whole team and smaller follow-up sessions as required. On the day of the workshop, we typically start with a product vision exercise such as the well-known Elevator Pitch or the Cover Story[8] format where the team describes what they would like to read about their product in a trade journal article a year from now. This shows whether the team has a common understanding about the general direction, or whether they might need to invest in some additional research (e.g., additional interviews, prototype testing, etc.). The next step is to look at the typical users of the product. If the workshop goal is to specify a detailed backlog, the user roles or personas should

This is also an aspect where design thinking practices and user story mapping work very well together.

1) starting with high-level usage steps, these are broken down into (2) finer activities per user role, which in turn are broken down into (3) concrete user stories in the format “as <role>, I want <functionality>, so that <value>.” These user stories add up to a first product backlog. This three-tier approach is especially useful for bigger projects. On each tier, the team can decide where it makes sense to drill down into the details and where dependencies to other teams need to be considered. This approach helps focus on the key development tasks at hand while keeping the big picture in mind.

To make the map easier to grasp, we use color-coded stickies for activities and user stories related to an individual persona or role, as...

you get an honest and tangible impression of the things that need further clarification. After the issues are on the table, it’s a lot easier to tackle them.

we use a simplified Kano model for the voting, which means that the teams tag user stories

“Must haves,” “Delighters,” or “Satisfiers.” These simple voting results are again a good basis for further alignment and validation with stakeholders, end users, and customers.

Our efforts at scaling user story mapping were successful. We ran more than 200 facilitated workshops in various units and locations, and now most teams are able to use user story mapping successfully on their own.

Documents usually describe what we need, but not why we need it.

If the person building software could simply speak with someone who understood the users who will be using the software and why they’ll be using it, there’s often a more cost-effective way to delight those users.

Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.

Kent’s idea was simple. If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way.

What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does. [For example,] if I type in the zip code and it automatically fills in the city and state without me having to touch a button.

I think that was the example that triggered the idea. If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it?

The bunch of cards that describes the whole product, or all the changes we’d like to make to a product we have, is called a product backlog.

Story conversations are about working together to arrive at a best solution to a problem we both understand.

If we build what we agree to, what will we check to see that we’re done? The answer to this question is usually a short list of things to check. This list is often called acceptance criteria, or story tests.

Discussing demonstration may add a few more bullets to your list of acceptance criteria.

The conversation goes best if it includes lots of things such as simple personas, workflow diagrams, UI sketches, and any other traditional software model that’ll help explain things. That way, you don’t have to just wave hands—you can point a lot, too. Whatever we bring into the conversation we’ll mark up, write on, correct, and change. We’ll even create a lot of things on the spot during that conversation. Use a whiteboard or flipchart paper. And don’t forget to take some “vacation

photos” before you leave. Photos of what you’ve created will help you recall all the details of the conversation that would be difficult to write down.