Overview
Based on User Story Mapping by Jeff Patton. Stories aren't just tickets - they tell a narrative. A story map has two dimensions: the user's journey across the top (the backbone), and depth below each step showing increasing detail. Releases are horizontal slices through the map, not vertical feature silos.
Workflow
Step 1: Build the Narrative Spine
Before writing individual stories, map the user's journey end-to-end. List the high-level activities in sequence - this is the backbone.
Example backbone for a checkout flow:
Browse -> Select -> Review Cart -> Enter Details -> Pay -> Confirm
Step 2: Identify the Walking Skeleton
The walking skeleton is the thinnest possible slice that completes the full journey. It's not an MVP of features - it's an MVP of the flow. Every step in the backbone needs at least one story.
Step 3: Write story headlines
Format: As a [user type], I want [goal], so that [benefit].
The "so that" clause is non-negotiable. If you can't write it, the story may not be worth building.
Step 4: Write Acceptance Criteria
Use Given/When/Then for each criterion:
Given [precondition]
When [action]
Then [expected outcome]
3-7 criteria per story. Cover: happy path, error states, empty state, edge cases.
Step 5: Slice into releases
Group stories into horizontal release slices:
- Release 1: Walking skeleton only - the minimum to complete the journey
- Release 2: Fill in the most important gaps
- Release 3: Polish, edge cases, power-user features
Step 6: Flag dependencies
Note stories that must complete before others. Untracked dependencies cause sprint failures.
Anti-Patterns
1. Vertical slices by feature
Bad: "Sprint 1: Build entire payment module."
Good: A thin horizontal slice that covers the full user journey, even if basic.
2. Missing "so that" clause
Bad: "As a user, I want to reset my password."
Good: "As a user, I want to reset my password so that I can regain access without contacting support."
3. Technical stories disguised as user stories
Bad: "As a developer, I want to refactor the auth module."
Good: Tech work belongs in tech debt tickets. If there's no user value, say so explicitly.
4. No walking skeleton
Bad: Writing 50 stories with no sense of minimum viable flow.
Good: Identify the walking skeleton first. Every story outside it is enhancement.
Quality Checklist