How to create a user story map, with a worked example

Most backlogs are a list. The top item is the most important, the next one slightly less so, and somewhere around ticket 140 nobody reads any more. Ask the team what a user can actually do after the next release and you get a pause, because the list was never arranged around the user in the first place.

A user story map fixes that by putting the backlog in the order of the user's day. This guide explains where the method comes from, walks through the five steps of building one, and then follows a single example from a blank wall to two release slices. The example is made up. It's a small bike repair shop that wants online booking, so you can check every count against the map without anyone's real data.

A note before we start. We make Prompt Board, and our user story map template is the same bike shop map, ready to edit. The method works just as well with index cards and masking tape.

What a user story map is

Jeff Patton described the idea in an article first published in 2008, The New User Story Backlog is a Map, and later in his book User Story Mapping (O'Reilly, 2014). The article starts from a complaint. "That's what a flat backlog is to me," Patton writes. "A bag of context-free mulch." It holds the stories but loses the story.

The map puts that story back in two directions:

• Left to right is the narrative. Patton's story mapping quick reference says the horizontal axis "is organized in the order you'd tell the story about your user to someone else."
• Top to bottom is priority. Under each step hang the stories that support it. The ones the user can't do without go high, the extras go lower.

The top rows form what Patton calls the backbone. In the 2008 article he explains the name: the big things along the top "look a little like vertebrae", and the cards hanging down "look a little like ribs".

The backbone has two levels. Activities are the big things a user does. Patton's article calls an activity "a big thing that people do", one with lots of steps. Under each activity sit the steps, which the quick reference calls user tasks and describes as "short verb phrases". In his email example, "read an email message" and "mark a message as spam" are tasks, and "going through my inbox" is an activity.

When a story map is worth the time

A story map earns its place when the question is "what's the smallest version we can release?" That happens before the first release of a new product, when a big feature has to ship in pieces, or when a team has inherited a backlog so long that nobody can say what a release delivers.

It's the wrong tool for a precise process. The quick reference says so directly: if you want "the precision of a workflow model, flow chart, or UML model, then a story map isn't your best choice." For that, draw a user flow. And if the question is how customers feel at each stage rather than what you should build, a user journey map fits better, with rows for what people do, think and feel.

How to create a user story map in five steps

Patton's quick reference lists five steps under the heading "Story Map Process". Here they are, with what each one looks like in practice.

1. Frame the map. Before any sticky notes, write a short brief. The quick reference splits it into what (the product or feature), who (the users, plus the "chooser" who buys it) and why (what the organisation gains). One paragraph is enough. It stops the map from growing to cover everything the company might ever build.
2. Map the big picture. Pick the user who matters most and tell their story from start to finish, one step per note, left to right. Patton's phrase for this stage is "mile-wide, inch deep". Get the whole story across before you go into detail anywhere. Group the steps into activities once you can see them; the quick reference notes that activities "often emerge after you see more of the story."
3. Explore. Now go down. Under each step, add the stories that would support it: smaller sub-tasks, variations, things that could go wrong and how the user recovers. The quick reference suggests playing "wouldn't it be cool if..." and asking what could go wrong. Scope comes later, so don't argue about it here.
4. Slice out viable releases. Draw lines across the map. The top slice should be the smallest set of stories that lets the user reach the goal. In the quick reference's words, "the smallest number of tasks that allow your specific target users to reach their goal compose a viable product release." Write each release's target outcome on a note to the left of its slice, and decide what you'd measure to know it worked.
5. Slice out a development strategy. Split the first release again, into the order the team will build it. Patton borrows chess terms here: an opening game that builds a "functional walking skeleton", a mid game that completes the major functionality, and an end game that refines the product for release.

Steps 1 to 4 are a workshop. Step 5 is usually a smaller conversation with the people building it.

A worked user story mapping example: booking a bike repair

Everything in this section is invented: the shop, its owner and the decisions. The point is to show the method with real-looking cards.

The brief

A bike repair shop with two mechanics takes all its bookings by phone. During the spring rush the phone rings while both mechanics have their hands in a gearbox. The owner wants customers to book online.

The team wrote this framing before mapping:

• What: online booking for repairs.
• Who: cyclists who need a repair this week. The owner is the chooser.
• Why: fewer phone calls during working hours, and fewer bikes dropped off without warning.

The backbone

The team told the story of one cyclist out loud and wrote a note for each step. It came to ten steps, which they grouped into five activities:

Their first draft had "Admin panel" and "Database" in the top row. Neither is something the cyclist does, so both came out. The work behind them is real, but it belongs to the stories that need it.

The stories and the first slice

Under each step the team added every story they could think of, then moved the ones the cyclist couldn't do without to the top. The first line went under those. That gave Release 1 one story under each of the ten steps:

Two of these involve no new software at all. "Shop phones about extra work" and "Pay at the counter" are how the shop already works. They stay on the map because the slice has to cover the whole story. Without them, Release 1 would be a booking form that leaves the cyclist guessing at the counter.

Online payment started in Release 1 and moved down. The team asked whether a cyclist could reach the goal without it. They could, since the counter takes cards, so it went to Release 2.

The outcome note to the left of Release 1 reads: "a cyclist books and collects a repair without phoning the shop". To check it, the owner will count how many bookings arrive online and how many by phone in the first month after launch.

Release 2 and later

Release 2 holds eight stories: a photo of the problem, time slots instead of whole days, saved bikes on an account, an add-to-calendar link, online quote approval, a status page for each booking, online approval of extra parts, and paying online before pickup. "Drop the bike off" and "Pick the bike up" get nothing new in this slice. Its outcome note reads: "fewer calls to ask where the bike is or what it costs".

Below that sits a third band called Later, with three ideas that have no release yet: rebooking the last service, a waiting list for full days and a reminder for the next service.

That's 21 stories in total: ten in Release 1, eight in Release 2 and three in Later.

What the map changed

The team's original plan was to build booking properly first: time slots, accounts and photos, then everything else. On the map that plan is one column deep. It would have produced a polished booking form and nothing for the cyclist after they hand over the bike. The first slice gives the cyclist a thin version of every step instead, and the next slice goes after the questions customers still phone about.

The same map, ready to edit

The user story map template on Prompt Board is this bike shop map: five activities, ten steps and the three bands of stories, each with its outcome note. Replace the user and the backbone with your own, then move the dashed lines as the conversation settles.

Common mistakes

• A backbone of system parts. "Login", "Database" and "Settings" are not things a user sets out to do. If a card on the top rows doesn't read as a verb phrase about the user, it belongs further down.
• Mixed goal levels across the backbone. The quick reference says that as you read across the backbone, the tasks should be "of a similar goal level". "Pay" next to "Choose the payment provider's API" is a sign one of them is in the wrong row.
• A first slice that is one column deep. Building one activity in full before the others exist is the flat backlog again, just drawn sideways. Every step the user needs should have something in the first slice, even if it's manual.
• Release lines with no outcome. Without the note on the left, a slice is a list of features. With it, the team can argue about whether a story serves the goal.
• Treating the map as finished. The quick reference's process page opens with "The story map evolves with your understanding of your users and your product solution." Keep it next to the backlog and move cards when you learn something.

Frequently asked questions

Who created user story mapping?

Jeff Patton. He described it in his 2008 article The New User Story Backlog is a Map and wrote the book User Story Mapping: Discover the Whole Story, Build the Right Product, published by O'Reilly in 2014.

What are the levels of a user story map?

Activities sit at the top, steps (Patton also calls them user tasks) sit under them, and the stories and details hang below. The quick reference lists what goes in that lower part as sub-tasks, alternative tasks, exceptions and details. Release lines then cut across all of it.

What is a walking skeleton in a story map?

It's the thinnest version of the product that still works from start to finish. In the 2008 article Patton notes that the stories placed high on the map describe "the smallest possible system you could build that would give you end to end functionality", and that this is what Alistair Cockburn calls the walking skeleton. In the quick reference it's what the opening game of the first release builds.

What is the difference between a user story map and a user journey map?

A journey map describes what customers do, think and feel at each stage, and where the experience could improve. A story map takes the user's steps as given and hangs the work to be built underneath them, sliced into releases. You can draw the journey map first and use its stages as a starting point for the backbone.

Map your own product

Book two hours with the people who know the users and the people who will build it. Open the user story map template, write your user and goal at the top, and tell the story out loud before anyone writes a story card. When the first slice is agreed, a MoSCoW board can settle what's left inside it, and our MoSCoW prioritization example shows the test to use. The product roadmap template is where the releases go once they have dates. If the map has to serve a quarterly goal, our guide to OKR examples shows how to write that goal so a release can be judged against it.