story-mapping

User Story Mapping Expert

Overview

Visualize the user journey and translate strategy into prioritized, deliverable work using Jeff Patton's user story mapping technique. Story maps shift teams from feature-first thinking to flow-first thinking -- understanding the complete user experience before deciding what to build and in what order.

A story map is a 2D grid: the backbone (activities → steps) runs left-to-right in the order users experience the journey, the body (tasks) hangs below each step ranked top-to-bottom by priority, and a horizontal MVP line separates Release 1 from later. See the playbook reference for full anatomy and the 6-step build sequence.

When to Use

• MVP definition -- Draw a clear line between "must ship" and "can wait."
• Release planning -- Sequence work across multiple releases or sprints.
• Cross-team alignment -- Give multiple teams a shared understanding of the user journey.
• Backlog reorganization -- Restore context and priority to a flat backlog.
• New product kickoff -- Decompose a vision into work from scratch.

When NOT to Use

• Purely technical infrastructure work with no user journey (use technical spikes).
• The team already has a well-prioritized, context-rich backlog.
• Single-feature work that doesn't span multiple user activities.

Clarify First

Before building the map, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• [ ] The user and their end-to-end journey — who travels it and the activities → steps in order (defines the backbone, the left-to-right spine of the map)
• [ ] The target release / MVP — what must ship first vs can wait (sets where the MVP line is drawn between Release 1 and later)
• [ ] The map's goal — MVP definition vs release sequencing vs cross-team alignment (changes how the body tasks are sliced and prioritized)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

References

• [references/playbook.md](references/playbook.md) — read this when building a map: story-map anatomy, the 6-step build sequence, the artifact template, map patterns (walking skeleton / thick slice / progressive enhancement), the workshop facilitation guide, troubleshooting, and success criteria.
• [references/red-flags.md](references/red-flags.md) — read this before using a map for release planning: common ways a story map goes wrong with bad/good quoted examples and fixes.

Scope & Limitations

In Scope: User story map creation, backbone and body decomposition, release slice definition, MVP scoping, facilitation guidance, workshop planning, template and pattern library.

Out of Scope: Individual story writing and acceptance criteria (see job-stories/ or agile-product-owner), technical architecture decisions, detailed effort estimation, sprint planning mechanics.

Important Caveats: Story maps are planning tools, not contracts. They should be updated as the team learns. A map created before building will always be wrong in details -- the value is in the shared understanding, not the artifact itself. Jeff Patton: "The map is not the territory; the conversation is the territory."

Integration Points

| Integration | Direction | What Flows |

|---|---|---|

| job-stories/ | Receives from | JTBD discovery canvas defines the narrative for mapping |

| create-prd/ | Feeds into | Release 1 tasks inform PRD scope (Sections 7 and 8) |

| prioritization-frameworks/ | Complements | RICE scoring prioritizes within release slices |

| brainstorm-okrs/ | Complements | Release slices align with quarterly OKR targets |

| outcome-roadmap/ | Feeds into | Release slices map to Now/Next/Later roadmap horizons |

| wwas/ | Feeds into | Tasks become WWAS backlog items with strategic context |

Further Reading

• Jeff Patton, User Story Mapping (2014)
• Jeff Patton, "The New User Story Backlog Is a Map" (2005)
• Inspired by Productside story mapping workshops