Story Mapping
Story mapping lays a solution's stories out on a two-dimensional grid. The top row carries, from left to right, the themes or activities of the customer's path, in the order the customer goes through them; under each theme the stories that deliver it are stacked in decreasing priority. The Agile Extension to the BABOK Guide gives the technique three purposes: to understand a product's functionality, to understand the flow of usage and to prioritise delivery. The map is made to stay on display: the team reads off it what the solution does end to end, what goes into the next release and what waits.
Goal
The technique produces a map, a grid whose horizontal dimension carries the sequence and the grouping of the product's main steps and whose vertical dimension carries the detail and the priority of the stories. It supports one decision: how the work is cut into releases, which the release line traces across the map. The Agile Extension to the BABOK Guide sees in it a way of understanding the need while concentrating the analysis on the highest-priority items.
The delivery team has the map in front of it during release planning sessions. Reading it makes visible the dependencies the intended flow of usage creates: a story that assumes another one delivered before it is spotted from their positions on the top row. The map also serves risk assessment, since it shows how the stories will have to work together to deliver business value.
The cards laid on the grid are stories already identified: the technique orders them and brings out the ones that are missing; it does not split a story that is too large. You will find the format of a story and its quality criteria under user stories. §7.20.2 of the Agile Extension calls story mapping a decomposition technique, in the sense that the reading descends from the end-to-end view to the detailed stories; splitting a story too large to be estimated or delivered belongs to story decomposition, covered in §7.18. §7.20.3.4 puts the two activities in order: the mapping session prioritises the stories at hand and designates those that will go on to elaboration or to decomposition.
Table 7.0.1 of the Agile Extension places the technique among those of requirements management, on the internal-team side.
Usage
When to use it
- Release planning: deciding what goes into the next release and in what order.
- Overview lost: a story's rank in a flat backlog no longer says where in the customer's path it serves; the map restores the end-to-end view during delivery.
- Functional gaps suspected: walking the top row brings the missing stories out.
- Several audiences to arbitrate: the map shows which personas each slice serves.
- Sequence to check: the intended flow shows which stories have to come before others.
- The route of a piece of data to understand: the map follows one data item through the system.
When not to use it
- A single story that is too large: the grid orders existing stories, reach for story decomposition.
- A context with no usage path: nothing to lay out on the horizontal axis, order the backlog with a prioritisation technique.
Description
The two axes
A map reads in two directions that answer two questions: from left to right, what the solution does end to end; from top to bottom, in what order the pieces arrive. The themes on the top row are laid out in the linear order a customer goes through them and cover all the known personas. Under a theme, the highest-priority story takes the top of the stack and the ones that follow run downwards.
The three structural elements
| Element | What it carries | What it lets you decide |
|---|---|---|
| Themes or activities | The top row: every known theme or activity, as a linear path. The guide cites the use of an ATM, from waking the machine to the choice between another transaction and leaving. | The scope of usage and where in the path each story sits. |
| Stories or functionality | Under each theme, every known piece of functionality attached to it. A story serves one persona or several. | What is left to build for a theme to hold. |
| Priority order | The stack from top to bottom under each theme. Rank puts at the head the stories that serve the most numerous and the highest-ranked personas, together with those whose delivery conditions the functionality that follows. | How the functionality divides between the releases. |
Building the map
- Prepare the themes and the stories before the session
The guide asks for it so that the group spends its time prioritising and understanding the customer's path rather than discovering the material. - Lay out the top row
A theme with no story signals a gap in the backlog or a theme outside the path. - Hang the stories under their theme
Each story joins the theme it delivers. A story that finds two themes is most often two stories. - Stack by priority
The order is argued column by column, then compared from one column to the next. - Draw the release line
It separates what ships from what waits. Patton runs it across the whole map, so that the first release gives a path a customer can walk end to end. - Read the map back end to end
What is still too large goes to decomposition, what is close to delivery goes to elaboration.
Running the session
The technique does without a dedicated facilitator. It is most often practised as a group, around the wall or the board. The product owner decides when a call is stuck. That economy comes from the preparation: if the themes and the stories arrive at the session on cards already written, the discussion is about where they belong, which is settled by moving a card.
What makes a map fail
The top row written in screens
When the themes copy the application's modules, the horizontal row stops carrying a path and the map turns back into a backlog in columns. The test: read the top row aloud; it has to say what a customer does, in the order they do it. "Entry screen, approval screen, reporting module" does not pass that test.
The release line that runs down one column
Delivering a whole theme before starting on the others gives a solution no customer can get through. A release that occupies a single column is recognised at a glance on the map.
The map taken for a dependency analysis
The guide states the limit: a map shows a flow without analysing or drawing the dependencies between requirements. It makes that analysis easier by showing the intended sequence; the analysis stays separate work, carried out on the requirements.
The map too big for a wall
On a wide-ranging solution a single map becomes unmanageable, and the guide provides for several maps covering a programme of work. The split is made by product or by usage domain, with an explicit joining point where a path crosses from one map to the next.
AI considerations
A language model shortens the preparation. From a documented process or from interview notes, it proposes a first row of themes in the order of the path, which the team corrects before the session. From a flat backlog, it groups the stories under candidate themes and flags the ones no theme takes in, often the first sign of a gap in the path. It writes up the missing stories that the read-back brings out.
The vertical order escapes the model. It is decided on revenue, contractual deadlines and regulatory obligations the model knows nothing about, and the release line commits the team in front of stakeholders. A map produced in one block and posted as it stands takes away the point of the session: the guide describes a group activity in which the discussion about the customer's path is worth as much as the grid it produces.
What goes into the model is a backlog export, where the stories of a banking application quote real customer data as examples. It does not go into a publicly hosted service until the use is covered within the meaning of the Federal Act on Data Protection (FADP).
Examples
A Swiss retail bank maps the payment of QR-bills in its e-banking application. The top row follows the customer's path: log in, scan the QR-bill, check the amount and the due date, confirm the payment, find the confirmation again.
The release line crosses the five columns. The first release takes the top story of each theme, which gives a customer able to pay a QR-bill end to end: opening the session, reading the code with the camera, checking the scanned amount against the paper bill, confirming with the second factor, a receipt as a PDF. Seven cards stay under the line and improve that path without conditioning it. Four of them spread one per column: the session kept open on a trusted device, typing the reference number by hand when the camera fails, the payment dated to the due date, the search through the history. The other three fall under "check the amount and the due date", which therefore counts four cards and becomes the tallest column: an amount left open for the customer to complete, a bill already paid the month before, a refusal above the daily limit of CHF 5'000.
Visualisations
The drawing carries three pieces of information an ordered list does not. The arrow along the top gives the order of the path, so a theme in the wrong place shows. The release line shows whether the release forms a slice across the whole map. The uneven height of the stacks indicates where the special cases gather.
That last reading serves estimation. A tall stack is a theme discussed down to its exceptions; a short stack says either that the theme is simple or that nobody has opened it yet. The second case is paid for in the iteration, when the unwritten exceptions arrive.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | Themes and stories are written before the session; the wall or the shared board is booked ahead and the group has to be brought together. |
| Execution | Medium | A session of two to three hours lays out the map of one product, with no dedicated facilitator but with the whole delivery group. |
| Documentation | Medium | The map is carried into the backlog tool and kept up to date at every change of priority: map and backlog diverge from the first repriorisation that is not carried over. |
Tooling
The wall and sticky notes are the original form and remain the best one for the first pass: the map is handled by several pairs of hands, it stays on display in front of the team and nobody waits their turn at the keyboard. It calls for a team gathered in one place and a wall wide enough.
The online whiteboard (Miro, Mural) carries the same handling for a distributed team, and the map survives the session in a form everyone can find again. The overall reading is poorer there than on the wall, since a screen rarely shows five filled columns without zooming.
The story mapping tools plugged into the backlog (Easy Agile for Jira, StoriesOnBoard, Avion) hold the map and the backlog on one set of data. What moves on the map moves in the backlog, which removes the re-entry after the session and the drift between the two views.
The backlog tool on its own renders the minimal service. An ordered list has no horizontal axis; a "theme" field on each story, plus a sort, rebuild a reading by column. What is lost is the overall view of the path.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.20 Story Mapping: the purpose of the technique, the two-dimensional grid, the elements (themes or activities, stories or functionality, priority order) and the facilitation, the map on display during release planning, the reading of dependencies and the risk assessment, together with the limitations stated, among them the absence of any analysis of dependencies between requirements, the size beyond which several maps become necessary and the contexts that are not process-oriented.
- IIBA, Agile Extension to the BABOK Guide, §7.0, table 7.0.1 Selecting the Right Technique: the technique placed among those of requirements management, on the internal-team side.
- Jeff Patton, It's All in How You Slice It, Better Software, January 2005, p. 16: the original article, which proposes cutting a delivery into slices that cross the whole path.
- Jeff Patton, The New User Story Backlog is a Map, 2008: the article in which Patton names the practice and describes the top row as the backbone of the product, read from left to right.
- Jeff Patton with Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product, O'Reilly Media, 2014, ISBN 978-1-4919-0490-9: the full treatment, including the minimal slice that crosses the whole path, which Patton takes from Alistair Cockburn under the name walking skeleton.