Stop shipping features out of context. Start building around what users actually do.

User story mapping is a technique Jeff Patton introduced in the mid-2000s as a fix for what was going wrong with flat backlogs. The idea: arrange user tasks as a left-to-right narrative — the backbone — representing the user's journey through your product. Beneath each task, stack the stories that support it. The horizontal axis represents time or workflow sequence. The vertical axis represents priority.

Instead of a ranked list, you get a two-dimensional map that shows the whole story at once. It was Patton's response to watching teams ship features that were technically correct but disconnected from user reality. His original thinking described it as "narrative flow" — talking about software not as a list of things to build, but as a sequence of things users need to do.

A story map has two layers:

• Backbone: The top row of high-level user activities — e.g., "Search for a product", "Compare options", "Complete purchase". These are the big steps in the user's journey, read left to right.
• Walking skeleton: The minimum set of tasks that creates a coherent end-to-end experience. This is your first release candidate — not the most polished experience, but one that works from start to finish.

Below the skeleton, stories are stacked vertically in priority order. What gets cut for the next release stays below the line. That visual cut across the map is the release boundary.

A flat backlog answers: "What do we build next?" A story map answers: "What does the user need to do — and how much of that are we building now?"

The difference matters when scoping. Backlogs optimize for completion; story maps optimize for coherence. Teams that plan purely from backlogs often ship half-finished workflows — every feature works individually, but the user still can't complete a meaningful task.

Story mapping forces a better question: if we cut everything below this line, can a user still do something useful? That's a stronger scoping test than ranking tickets by priority.

Story mapping pays off most when:

1. You're starting a new feature area and need to align product, design, and engineering on scope
2. You're running a discovery sprint and want to see gaps in the current experience
3. Your backlog has grown messy and priorities have lost their relationship to actual user journeys

It's less useful for pure maintenance work or well-understood incremental improvements where everyone on the team already shares the same user context.

Teams new to story mapping often turn it into a feature inventory. They list every possible task, stack stories underneath, and end up with a map that's just a fancier backlog. The point isn't to capture everything — it's to force a conversation about what the minimum viable journey actually looks like.

A good story mapping session ends with a clear answer: here's the smallest slice of experience that delivers real value to a real user. Everything else is a future sprint. That clarity is worth more than any amount of ticket refinement.