Story Map
Short Tip: A technique used for structuring product requirements based on the user’s journey.
What is it?
It is a technique created by Jeff Patton in his book User Story Mapping: Discover the Whole Story, Build the Right Product. It is based on the organization of main product requirements from a user journey perspective.
Why use it?
A traditional Product Backlog incorporating Epics and user stories can be difficult to understand, especially for complex products. In these cases, refining the Product Backlog may not be productive, since details end up being discussed without a broader view, which causes disengagement and lack of collaboration.
The Story Map has the great benefit of grouping the stories within Epics and making it easier to view their relationship with the user’s journey. Additionally, the Story Map can be used as a structurer of product releases. Because it is a collaboration-intensive technique, there is greater team engagement in a productive discussion.
How to use it?
There are variants on how to structure a Story Map. One of the commonly used ways includes the following steps:
- Indicate clearly at the top of the Story Map who the product’s user is;
- Identify, from this user’s perspective, the major actions he/she performs when interacting with the product, in its logical use sequence. These actions will be called “tasks”;
- Group these tasks logically, according to the goal the user wants to achieve. These items will be placed above the tasks and will be called “user goals” or simply “goals”;
- List the Epics and user stories below each task. Don’t worry at this point about using a complete user story format, the important thing is to engage in the discussion flow from the user’s perspective.
- Organize the Epics and stories by priority (the top ones have highest priority). The MoSCoW (Must, Should, Could, Would) technique can be used here.
- Organize large groups of stories in releases. The first one is usually considered the product’s MVP (Minimum Viable Product) and is highly important. The goal here is not to set dates, but identify interdependencies between user stories and the value generated for the user.