User Story Mapping
Definition
User Story Mapping
User story mapping is a planning technique that lays product work out as a two-dimensional map rather than a flat list. The map keeps the user’s story intact, so a team can see the whole journey before deciding what to build first.
Jeff Patton named the practice. He sketched the idea in 2005, described it properly in 2008, and later wrote the book — co-authored with Peter Economy — that carries the term as its title.
The problem it solves is easy to state. A prioritised backlog tells you what comes next, but it never tells you what the product does from end to end.
Pull the top ten items off a flat backlog and you usually get ten disconnected fragments. Pull the top slice off a story map and you get a thin but working version of the whole thing.
Key takeaways
- A story map orders work along two axes: user activities left to right, supporting stories top to bottom.
- The horizontal row of activities is the backbone, and its items are not ranked against each other.
- Releases are cut as horizontal slices through the map, so each one delivers a complete path.
- A flat backlog loses the narrative, which is the specific failure story mapping was invented to fix.
How it works
A story map has two axes. User activities run left to right in the order someone performs them, and the tasks and stories that support each activity hang vertically beneath it, ordered by priority rather than by sequence.
Agile Alliance’s glossary describes ordering user stories along two independent dimensions, with activities following roughly the order a user works through them and stories descending by priority.
The top row is the backbone. Jeff Patton’s write-up places user activities across the top of the map and calls those big items the essential capabilities the system needs, which is why you do not rank them against each other.
| Layer | What sits there |
|---|---|
| Backbone | User activities, left to right in the order people actually do them |
| Tasks | The steps under each activity, broken down into user tasks and sub-tasks |
| Slices | Horizontal swim lanes cut across the whole map, one per release |
Slicing is where the map earns its keep. You draw a horizontal line across every column and take the stories above it, which gives you a release that touches each activity rather than finishing one column perfectly.
Patton calls the first slice a set of swim lanes, one per release, and moves stories up or down between them. Agile Alliance uses the phrase walking skeleton — a barebones but usable version of the product.
Building a map takes a room and a wall. The team writes activities on cards, lays them out in sequence, then hangs tasks underneath until the gaps and the duplicated thinking become obvious.
Sub-tasks sit below the tasks. One task such as “verify the customer” can fan out into three or four cards, and only some of them belong in the first release.
The gaps are the point. A flat list hides them, because nothing in a list says what should have been next.
Keep the map alive after the workshop. Teams that photograph the wall and never touch it again lose the narrative just as surely as teams that never mapped at all.
Examples
Story maps show up wherever a team has to agree on scope without losing the user’s journey. Three settings make the pattern concrete, and each one slices the same map differently depending on what the first release has to prove.
An online retailer replatforming its storefront maps the backbone as browse, search, add to basket, check out, pay, track and return. The first slice is the thinnest path that gets one real order out of the door.
A bank building a mobile onboarding flow maps identity capture, document upload, checks, approval and first login. Risk and compliance sit in the room for the slicing conversation, not afterwards.
A BPO standing up a new client workflow maps an agent’s day instead of a customer’s. Activities become receive, verify, action, escalate and close, and the first release covers the three ticket types that make up most of the volume.
Teams often pin a customer journey map beside the story map so the two stay honest with each other. The story map says what gets built — the journey map says what the person experiences.
Related terms
Story mapping sits between discovery and delivery, so it borrows vocabulary from both. The entries below cover the roles, research inputs and planning artefacts a mapping session usually pulls into the room with it.
- Product Manager: the role that owns what gets built and in what order.
- Minimum Viable Product: the smallest release that still tests a real assumption with real users.
- UX Researcher: the specialist who supplies the evidence about how people actually work.
- Design Thinking: the problem-framing approach that often precedes a mapping session.
- Roadmap Prioritization: the process of deciding which slices ship in which order.
FAQ
Who invented user story mapping?
Jeff Patton. He introduced the idea in 2005, published “The New User Story Backlog is a Map” in 2008, and co-wrote the book User Story Mapping with Peter Economy.
What is the backbone of a story map?
The backbone is the top row of user activities, arranged left to right in the order a person performs them. Items on the backbone are not prioritised against each other.
How is a story map different from a backlog?
A backlog is one ranked list. A story map keeps the same stories but arranges them against the user’s journey, so you can see what a release leaves out.
How do you slice a story map into releases?
Draw a horizontal line across the whole map and take everything above it. Each slice should deliver a usable path through every activity rather than one finished column.
How many stories belong in the first slice?
Only as many as it takes to get one complete journey working, since the point of the first slice is a thin end-to-end product rather than a finished feature.
Explore the Outsource Accelerator site for more on how outsourced product teams plan and deliver work.
Independent
