By day I'm a Product Owner at ING, and the tool the role hinges on is the Product Backlog. The Scrum Guide describes it as an ordered list. A list can tell you what comes next. What the items have to do with each other, and what story they tell together, it can't. That's exactly where story mapping comes in.
The post on silos was about how the user's journey gets lost when every team only sees its own section. A flat backlog can do the same thing, just inside a single team.
Why the list loses the thread
Jeff Patton described the problem in 2008, in a blog post whose title is still the whole argument: The New User Story Backlog is a Map. His objection was simple. Lining stories up in the order you'll build them doesn't help you explain to others what the system actually does. He calls the flat backlog "a bag of context-free mulch."
In day-to-day work this shows up in three places:
- Completeness. Whether a list of eighty stories covers everything someone needs to reach a goal is impossible to tell by looking at it. The gap only shows when someone uses the finished product.
- Release planning. With a hundred items, every story gets judged on its own as "in" or "out". That the three most important stories don't yet add up to a path anyone can walk from start to finish stays invisible.
- Conversation. Someone new to the team reads a backlog like a phone book. The story behind it lives in the heads of the people who've been around longer.
What a story map is
In 2014 Patton worked the method out in his book User Story Mapping, written with Peter Economy and published by O'Reilly. The subtitle sums up the goal: discover the whole story, build the right product.
The map runs in two directions:
- Horizontally, the backbone (a term Patton credits to Dan Rawsthorne). At the top sit the big activities users carry out, beneath them the individual steps, left to right in the order you'd tell someone how the product gets used.
- Vertically, the details. Under each step hang the stories that implement it, sorted by necessity: the essentials at the top, variants, convenience and edge cases further down.
Releases are drawn as horizontal slices across the map. Patton used masking tape on the wall for this and moved the cards into the lanes. The first slice is the walking skeleton, a term from Alistair Cockburn: the smallest system that works end to end.
An example: an evening with an audiobook
To illustrate, here's a map for an audio player like CLAUDIO, my app for audiobooks, music and podcasts from your own collection. I drew it for this post; it isn't the document the app was built from. The story is one evening: someone listens to an audiobook from their own collection, whether it's a file in iCloud Drive or on an Audiobookshelf server.
| Connect the collection | Find something | Listen | Pick up later |
|---|---|---|---|
| Pick a local file or iCloud Drive | See audiobooks as a list | Play and pause | Resume at the same spot |
| Enter a server address | Search and filter | Jump between chapters | Sleep timer to end of chapter |
| Merge several servers | Series with volume numbers | Adjust speed | Offline cache for the road |
The header row is the backbone, and necessity drops from top to bottom. A table makes a weak map, because it squeezes activities and steps into one row, but it carries the principle: the first row on its own is already a path from left to right, and that's the walking skeleton.
Building a map as a team
Roughly, and following Patton, it goes like this:
- Tell the story, don't list the features. Someone on the team narrates what a person does with the product, step by step, in the present tense. Every step becomes a card. Whoever says a feature ("search function") gets asked for the step ("finds last night's audiobook again").
- Order the backbone. The steps go in narrative order, and related steps get an activity above them. The backbone isn't prioritized; it describes the path.
- Go wide underneath. For each step the team collects variants, error cases and alternatives. At this stage more is better; cutting comes later.
- Draw the walking skeleton. The first line runs across every column. Above it goes only what a person needs to walk the path once from start to finish, even if it's bare at every point.
- Slice by outcome. Every further slice gets a sentence saying what users can do afterwards that they couldn't before. In the example, say: "Listen while falling asleep without losing the thread" (sleep timer to end of chapter, resuming at the right spot) or "Listen on the road without a network" (offline cache). A slice that's just called "package 2" is a feature bundle, not a release.
In the book Patton argues that the job isn't to build more software faster, but to get as much outcome and impact as possible from what you choose to build. The outcome sentence above each slice is where that stance ends up on the wall.
Common mistakes
- The map as a one-off artifact. It comes out of a workshop, gets photographed and is never touched again. After that the team works from the list, and the map goes stale with every sprint. A map only stays alive when slices move, cards get done and new findings get pinned in.
- Too fine-grained. Once sprint-sized tickets hang under the backbone, the map grows as big as the backlog and just as unreadable. On the map it's enough for a step to be recognizable; breaking it down happens when its slice is up.
- The map as solo work. A map the product owner puts on the wall alone is a document, not a shared understanding. Patton's central point in the book is that shared documents don't produce shared understanding. Development, design and the business side belong at the wall, because that's where the questions come up.
- Features instead of user steps. A backbone of "login, library, player, settings" is the app's navigation structure, not the user's path. That leads straight back to what the silo picture shows: every area is complete on its own, and the path between them is missing.
Story maps and discovery
The map shows not only what gets built, but also where the team knows too little. A step with three cards full of question marks is a sign that someone needs to talk to users or test a prototype there before a slice is worth it. A slice can therefore have a learning goal: what does the team need to know before it settles the next slice? Discovery gets a place on the same wall as delivery, instead of disappearing into a separate document.
Story maps and acceptance criteria
In 2001 Ron Jeffries split the user story into three parts: Card, Conversation, Confirmation. The card is a promise of a conversation; the confirmation is the acceptance tests that show the story has been implemented. The map provides the cards and the place where the conversation starts. Acceptance criteria come about when a slice is up, not before.
The card's position on the map helps here. A criterion like "the sleep timer stops at the end of the chapter" is, on its own, a feature description. Under the step "Pick up later" and in the slice "Listen while falling asleep without losing the thread", it turns into a testable question: does the audiobook resume the next evening where someone fell asleep? The slice's outcome sentence is often already the end-to-end check that belongs at the end.
Story maps and coding agents
The post on product owners and AI agents was about an agent knowing only what's written down and guessing the rest. The map is a good source for exactly the part that's usually missing from tickets. Which step does the story belong to? What outcome is the slice meant to achieve? What sits below the line and is explicitly out of scope? The boundary a team knows in passing is masking tape on the map. For an agent it has to be put into words. The agent doesn't need to read the map itself for that.
Conclusion
A backlog answers the question of what comes next. A story map answers the question of what for. For product owners it's not a second set of documentation next to the backlog, but the view a good ordering grows out of: a backbone of steps, slices by outcome, and people in front of the wall asking questions the whole time.
Sources
- Jeff Patton: The New User Story Backlog is a Map - flat backlogs, backbone (term after Dan Rawsthorne), walking skeleton (term after Alistair Cockburn), release lanes made of masking tape (October 8, 2008)
- Jeff Patton with Peter Economy: User Story Mapping: Discover the Whole Story, Build the Right Product - O'Reilly, 2014; outcome over output, shared understanding over shared documents
- Jeff Patton & Associates: Story Mapping - the author's overview, the map as a model of the user's journey through the product
- Ron Jeffries: Essential XP: Card, Conversation, Confirmation - acceptance tests as the confirmation of a story (August 30, 2001)
- Ken Schwaber and Jeff Sutherland: The 2020 Scrum Guide - the Product Backlog as an ordered list