User Story Mapping: How to Build One With Examples

By Tara Minh · Updated Oct 12, 2026

User story mapping is a planning technique that arranges user stories in a two-dimensional map. The horizontal axis follows the user's journey from left to right, and the vertical axis ranks stories by priority. Teams use it to see the whole product, find the smallest useful release, and slice the rest into later releases.

Key Facts

• Jeff Patton's post "The New User Story Backlog is a Map" was first published on October 8, 2008, and later expanded into his book User Story Mapping.
• A story map has a top row of big user activities (the backbone), smaller user tasks beneath them, and stories hanging below the tasks.
• Patton notes that a first-cut backlog often reaches "120 or so stories," which is why a flat list stops being readable.
• The highest row of the map describes the smallest end-to-end system you could build, which Patton calls the walking skeleton (a term he credits to Alistair Cockburn).
• Release planning is done with horizontal slices across the map, one slice per release.

What is user story mapping?

Most teams start with a product backlog: one long list, ordered top to bottom. That works for ten items. At a hundred it hides the very thing a team needs most, which is context. You can't tell why a story exists, what it belongs to, or whether the release you're planning would actually let a user finish anything.

Patton's fix is to lay the stories out as a map. In his original post, he describes the top of the map as big "user activities" and the items beneath as smaller "user tasks," arranged in the order you'd explain the system's behavior to someone. Stories sit under the tasks they belong to. Instead of scanning a list, you read the map left to right like a story, then top to bottom like a priority list.

Three ideas carry the whole technique:

• The backbone. The top row of activities, running in the order users do them. Patton credits the term to Dan Rawsthorne.
• The walking skeleton. A thin end-to-end slice that touches every part of the backbone. It's the smallest thing you could ship that still works from start to finish.
• Release slices. Horizontal bands across the map. Everything in the top band ships first, the next band second, and so on.

And one rule keeps it honest: you prioritize stories within a task, not whole activities. Nobody ships a car without brakes, so you don't rank "steering" against "stopping." You decide how good the brakes need to be in version one.

How a story map is structured

Picture a map for an online grocery ordering app. Read the layers from top to bottom.

If you've read about epics, features and stories, the mapping is easy: activities usually correspond to epics or themes, tasks to features, and the stories are the stories. The difference is that a story map shows all three levels in one picture instead of three separate lists.

User story mapping vs other planning techniques

A map isn't a replacement for everything else. It sits between discovery and delivery, and it's worth knowing where it overlaps with its neighbors.

A common combination: use impact mapping or a journey map to decide what outcome you're chasing, build a story map to turn it into a plan, then move the top slice into your backlog for sprint planning.

How to build a user story map step by step

You can do this on a wall with sticky notes or in any online whiteboard. Plan for a half day with the product owner, a designer, a developer, and someone who knows the users well. A small mixed group beats a big one, because the conversation is the point.

1. Frame the goal and the user. Write one sentence on who the map is for and what they're trying to achieve. If you have more than one user type, make a map per type, or a lane per type. Don't try to cover everyone at once.
2. Tell the story out loud. Have someone narrate how the user goes from start to finish. Write each step as a verb phrase on a sticky note ("Find products," "Pay") and place them left to right in the order they happen. This is your first draft of tasks.
3. Group steps into activities. Cluster related steps and give each cluster a larger label. Those labels form the backbone across the top. Reorder until the sequence reads naturally. Don't worry about completeness yet.
4. Explore each step in depth. Under each task, ask "what else could the user do here, and what could go wrong?" Add variations, edge cases and alternatives as new notes directly beneath. This is where the list of stories grows. Patton notes that a first-cut backlog often reaches 120 or so stories, so don't be alarmed when the wall fills up.
5. Write the stories. Turn each note into a proper user story once the group agrees it belongs. Keep them small enough to pass the INVEST criteria, and capture the detail in acceptance criteria later, not on the map.
6. Prioritize vertically. Within each task, move the essential stories to the top and the nice-to-haves lower. A story's height is its necessity. Don't rank across activities.
7. Find the walking skeleton. Draw a line under the highest row of stories that, taken together, lets a user complete the journey end to end in the simplest possible way. This is your first release candidate.
8. Slice the rest into releases. Draw more horizontal lines below the skeleton. Each band is a release or milestone that adds value on top of the one before. Give each slice a named outcome, not just a list of stories.
9. Estimate and check capacity. Size the stories with your usual method, such as story points, and see whether the first slice fits your time and budget. If it doesn't, move stories down or cut the skeleton thinner. Don't squeeze more in.
10. Keep it on the wall. Patton recommends treating the map as an information radiator, something the team can see all day. Pull stories from the top slice into the backlog as you plan sprints, and update the map as you learn.

A worked example: booking app for a physiotherapy clinic

Here is a small map for a clinic's online booking tool. The backbone has four activities, and each column shows tasks and stories top to bottom in order of necessity. The slices run across.

Look at what the skeleton gives you. A patient can find a clinician, book a slot, pay and get a confirmation. It's ugly and manual in places, but it works from end to end, so you can put it in front of real users and learn. Nothing in Slice 1 depends on something in Slice 3, and nothing is missing that would make the first release unusable.

A flat backlog would have mixed "exercise plan after each visit" in with "enter card details," and someone would have had to guess which came first. The map answers that visually.

User story mapping template

Copy this table into a whiteboard, spreadsheet or document. Replace the placeholder text and add as many columns as your journey needs. Keep activities in the order users do them.

Supporting fields to record alongside the grid:

User story mapping examples by business function

The technique started in software product work, but any team that delivers something in steps can use it. Swap "user" for whoever the work is for.

Product. Map a new onboarding flow. Activities: Sign up, Set up workspace, Invite teammates, Get first result. The skeleton is the shortest path to the first result, with defaults filled in. Slice 2 adds personalization, and Slice 3 adds integrations.

Marketing. Map a campaign launch. Activities: Plan, Create assets, Publish, Measure. The skeleton might be one landing page, one email and a basic tracking link. Later slices add paid channels, localization, and a dashboard.

Sales operations. Map a new lead-to-deal process. Activities: Capture lead, Qualify, Hand off, Close, Onboard. The skeleton is a form that creates a record and routes it to one owner. Later slices add scoring, automatic assignment and follow-up reminders.

HR. Map an employee onboarding program. Activities: Before day one, First day, First week, First 90 days. The skeleton is a checklist that covers accounts, equipment and a first-day schedule. Slices after that add buddy matching, training paths and feedback surveys.

IT. Map an internal service desk rollout. Activities: Raise a request, Triage, Resolve, Close and report. The skeleton is a single shared form and queue. Later slices add categories, service-level timers and a knowledge base.

Customer support. Map a help center. Activities: Find an answer, Contact support, Track the issue, Give feedback. The skeleton is search plus a contact form. Later slices add live chat, status pages and satisfaction scores.

In each case, the question for slice one is the same: what is the thinnest thing that lets someone get from start to finish?

User story mapping dos and don'ts

Do:

• Include people who build, design and use the product in the same room.
• Keep activities as verb phrases the user would recognize, not internal feature names.
• Slice by outcome, so every release lets a user do something new and complete.
• Keep stories small and leave the detail for later conversations.
• Revisit the map after each release. What you learn in Slice 1 should change Slice 2.
• Park ideas visibly below the last slice instead of arguing about them.

Don't:

• Don't rank activities against each other. They're all part of the journey.
• Don't build the map once and file it away. A map nobody looks at is just a drawing.
• Don't turn the backbone into a list of features or departments. It should follow the user's sequence.
• Don't slice by technical layer (database first, then screens). That produces releases nobody can use.
• Don't write acceptance criteria on the map. The sticky note is a reminder to talk, not a specification.
• Don't skip the walking skeleton and go straight to a "nice" first release. The skeleton is how you test your biggest assumptions cheaply.

Start with one journey

Pick one user and one journey, book a half day, and build the first map on a wall. Aim for a skeleton you could put in front of someone within a few weeks. You'll learn more from the arguments over where a sticky note belongs than from any template, and you'll leave with a shared picture of what you're building and the order you'll build it in.

Related reading

• User Stories
• Epics vs Features vs Stories
• Product Backlog
• Backlog Refinement
• INVEST Criteria
• Acceptance Criteria
• Story Points
• MoSCoW Prioritization
• WSJF Prioritization