User Story Map
It was developed by Jeff Patton, who first described it in an article in 2005 and in depth in the book User Story Mapping (2014).
Description
Unlike a flat Product Backlog (an ordered list of stories), the story map preserves the user's narrative: how someone uses the system from beginning to end. This makes it possible to see the "forest" (the complete experience) without losing sight of the "trees" (the individual stories).
The map is organized along two axes:
- On the horizontal axis, the activities and user tasks (written as short verb phrases: "issue invoice," "upload an expense") placed in their narrative order form the backbone of the map, which reads from left to right and tells what a person does with the product from beginning to end.
- On the vertical axis, beneath each task hang the details and variants, ordered by need. The horizontal lines drawn across the map separate releases, each with the outcome it is expected to achieve.
It also has two uses:
- The map of what already happens is documented with data (interviews, analytics, observation);
- the map of what you want to achieve is a hypothesis until it is released and measured.
Treating the second as an approved plan turns the map into a project document.
How to build it
- Define the users and their goals: who uses the system, and for what?
- Map the backbone: identify the major steps in the user's workflow (the epics) and arrange them from left to right in the order in which they occur over time.
- Fill in the activities: for each epic, identify the specific tasks the user carries out.
- Identify stories: for each activity, write the corresponding user stories and arrange them vertically by priority.
- Slice releases: draw horizontal lines that separate the stories into groups, each forming a coherent version of the product. The stories above the first line are the MVP.
What it is for
- As a discovery tool: building the map as a team helps detect gaps in the understanding of the user's flow.
- As a release planning tool: the cut lines make it possible to plan releases that are coherent experiences, not lists of features.
- As a tool for communicating with stakeholders: the map is understandable to non-technical people and facilitates the conversation about priorities.
Common mistake
Building the map alone or transferring it directly from the Product Backlog. The value of a story map lies in the collaborative process of building it: the conversations it sparks among the team, the Product Owner, and the stakeholders are the main source of learning. A map built individually or generated automatically from an existing backlog skips that process and produces a visual artifact without the shared knowledge that makes it useful.
Resources
🏦 Skill User storiesState of the art and development guide · Skill Arena
📄 Product Owner v.2.0Free download [in Spanish] · Scrum Manager
References
- Patton, Jeff. (2014). User Story Mapping: Discover the Whole Story, Build the Right Product. O'Reilly Media.
See also
Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.