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 — 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 — 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

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