What is user story mapping?
User story mapping was invented by Jeff Patton and described in his 2014 book User Story Mapping. The core insight is simple: a flat backlog loses context. When you see 200 tickets in a list, you don't see the user's journey - you see noise.
A story map adds a second dimension. Instead of just priority (top to bottom), you also capture narrative sequence (left to right). Read across the top row and you understand the product. Drill down in a column and you see the detail behind each step.
Think of it as a comic strip of your product. Read it left to right and you tell the user's complete story.
The map has three layers: Activities at the top define the broad goals. Steps below them break those goals into concrete actions. Stories at the bottom are the specific things to build. You prioritise by slicing horizontal cuts across the map - each cut becomes a release.
Activities, Steps & Stories
Every story map - regardless of product size - uses the same three-level hierarchy. Understanding these three levels is the foundation of everything else.
The "what" - high-level user goals
Activities represent the broad things a user wants to accomplish with your product. They live across the top of the map and define the left-to-right narrative sequence of the user's journey.
- Keep them broad - they're goals, not tasks
- Most products have 5–15 activities
- The order matters: left = earlier in the journey
- Examples: Sign up, Browse catalogue, Check out, Get support
The "how" - concrete user actions
Steps (sometimes called user tasks) break each activity into the individual actions a user takes to complete it. They sit directly below their parent activity, still reading left to right.
- Each step is a single, concrete action
- They should be at the same level of granularity
- Ask: "What does the user actually do here?"
- Examples: Sign up, Verify email, Create Map
The "build" - what engineering ships
Stories are the user-facing features and tasks your team actually builds. They live below their parent step. The same stories appear in your kanban board and release planner - they're the single source of truth.
- Written from the user's perspective
- Multiple stories per step is normal
- Stories stack vertically - top = highest priority
- Each story has a status: To Do, In Progress, Blocked, Done
The mapping process
A story mapping session typically involves the whole product team - product, design, and engineering. The goal is shared understanding, not just a filled-in spreadsheet. Here's the high-level process:
Set the goal
Start with a question: Who are our users, and what problem does this product solve for them? Write it at the top of your map. This keeps the session focused and prevents scope drift.
Define the user journey (Activities)
Walk through the product from the user's perspective and name the major stages. These become your Activities. Don't overthink them - you can rename later. The goal is a left-to-right narrative of what the user does.
Break each activity into Steps
Under each Activity, add the specific actions a user takes. Keep them at the same grain - "concrete user action" is the right level. If a step feels too big, split it. If it feels too small, roll it up.
Brainstorm Stories
Under each Step, add the features, screens, and tasks that need to be built. Don't filter yet - dump everything the team can think of. You'll prioritise in the next step. More stories is better at this stage.
Slice into releases
Draw horizontal lines through the map. Everything above the first line is Release 1 - your MVP. The second band is Release 2, and so on. The goal is that each release delivers a complete, usable slice of the product, not just a collection of features.
Run it as a workshop. Story mapping works best as a live session with the whole team - not something you fill in alone and hand over. The conversation is the value.
Top-down: backbone first
The backbone-first approach is the classic way to start a story map. You build the skeleton of the map - Activities and Steps - before writing a single Story. This works well when you have a reasonably clear vision of the user journey and want to establish structure before diving into detail.
Build the backbone, then fill in the stories
Walk through the product end to end. Name every major thing a user does. Keep them high-level - typically 5–12 activities.
Break each Activity into the concrete user actions. This gives you the full backbone - the "walking skeleton" of the product.
Now that structure exists, brainstorm Stories under each Step. The map fills out from top to bottom.
- You have a clear product vision and understand the user journey
- You're working on an existing product or a well-understood domain
- You want a structured, methodical session that's easy to facilitate
Bottom-up: task storming
Task storming flips the order. Instead of building the skeleton first, you start by dumping every task and story the team can think of - then you cluster, name, and organise them into a structure. This works well when the domain is uncertain, the team is new, or you want to surface hidden complexity quickly.
Brainstorm everything first, then find the structure
Everyone writes tasks on sticky notes - as fast as possible, no discussion. The goal is quantity. Don't evaluate, don't organise yet.
Group the cards into clusters of related work. Don't name the groups yet - just look for natural groupings. This usually surfaces 4–10 clusters.
Give each cluster a name. Broad clusters become Activities. If a cluster has sub-clusters, those become Steps under a shared Activity.
- The domain is new or complex and you're not sure of the user journey upfront
- You want to surface hidden scope that a structured approach might miss
- The team is large and you want everyone's ideas in the room immediately
Which approach should you use?
Both approaches produce the same output: a structured map with Activities, Steps, and Stories. The choice is about how you get there.
Planning releases
Once you have your map, the most important step is slicing it into releases. This is where story mapping earns its place over a flat backlog.
Draw a horizontal line across the map. Everything above the line is Release 1. The line should be drawn so that the top row of each column tells a complete, usable story on its own - this is the walking skeleton of your product.
A release must tell a complete story. Don't slice vertically (a full activity done, others untouched). Slice horizontally - a thin slice across all activities delivers more user value than one deep, one untouched.
The key rule: each release must work end to end. If a user can sign up, create a map, add a few stories, and share a view-only link - that's a usable product, even if it's thin. Release 2 then makes it better.
This thinking changes the prioritisation conversation. Instead of asking "which features are most important?", you ask "what's the thinnest slice that delivers a complete user experience?"
Story mapping in Runer
Runer is built around the three-level hierarchy. Every map enforces Activities → Steps → Stories, so your maps stay readable as they grow.
Story Board view
The classic story map layout - Activities across the top, Releases as horizontal swimlanes, Stories filling the cells. Add, rearrange, and reprioritise with drag & drop.
Kanban view
The same stories rendered as a status board - To Do, In Progress, Blocked, Done. Filter by release to focus on what's shipping now.
Releases view
One release at a time, with a progress bar and story list. Perfect for sprint review and stakeholder updates.
Sharing
Share individual maps with view-only or edit access. Anonymous links require no account from recipients.
Further reading
The sources below shaped the ideas on this page. If you want to go deeper on any aspect of story mapping, these are the primary references.
The definitive book on story mapping. Covers the full method from the ground up, including both the backbone-first and task-storming approaches described in this guide. Patton also introduced the concept of slicing maps into outcome-focused releases rather than arbitrary sprints.
The short paper that started it all. Patton's core argument: a flat backlog destroys context. Adding a narrative sequence axis transforms a list of features into a map of the user's experience.
Cagan's framework for product discovery at tech companies. Story mapping is recommended as a core technique for the discovery phase - specifically for understanding the user journey before deciding what to build.
Torres positions story mapping as a natural output of the opportunity-solution tree process. Once you have a clear opportunity, a story map helps you plan the solution space before committing to build.