Story Map
The user's activities across the top, the supporting detail beneath, sliced into releases that each work end to end.
Definition
Story mapping arranges work by the user's journey rather than by a flat backlog, which makes it visible whether a proposed release actually delivers a usable whole.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Fill it in
Loading your draft…
Saved in this browser only. Nothing is sent anywhere.
Backbone
The big steps, left to right, in the order the user does them.
The specific things a user does within each activity. One line each.
Slices
Each slice must be usable end to end. A release that covers only the first two activities is not a release.
One path through every activity, with everything optional removed.
What the first slice made obvious was missing, plus the next most valuable capability.
Everything not yet justified. Keeping it visible stops it being rediscovered every planning cycle.
Checks
Walk it through as a person, not as a feature list. If any activity has nothing in the slice, it does not work.
Record the rejections so the same debate is not repeated.
Cutting the first slice
The backbone is the easy part. The value of the map is in whether the first release is a usable whole or a set of fragments.
- 1
Walk the backbone end to end
Read the activities aloud in order. Anything nobody can narrate is either missing or in the wrong place.
- 2
Find the thinnest complete path
One option at each step, no variations, no optimisations. The test is whether a real person could finish the journey with only this.
- 3
Check it delivers something
A slice that leaves the reader mid-task is not a release, whatever it contains. This is the check flat backlogs cannot make.
- 4
Push everything else down
Variations, edge cases and enhancements sit beneath the line, visible rather than deleted, so their absence is a decision.
- 5
Look for the stranded requirement
Support, migration, permissions and admin are what usually get cut from a slice and block its release.
- 6
Name what the slice is for
Learning something, serving a segment, or replacing an existing path. Each implies a different cut.
Keeping the map honest
Do
- Build it with the people who will implement it, since the map is mostly the conversation.
- Keep the backbone in the user's language, not the system's.
- Leave the parts you are not building visible beneath the line.
- Revisit it when scope changes, rather than treating it as a workshop artefact.
Do not
- Do not slice by component or by team, which produces releases nobody can use.
- Do not let the first slice grow until it is the whole product with a different name.
- Do not map at a level of detail nobody can read across.
- Do not convert the map into a flat backlog and then throw the map away. The order is the information.
Slicing across, not down
Local chart
TPL·006 · Region VIII · Grid H3
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Often used with
These usually appear in the same screen or the same decision.
- Pareto PrinciplePRIN·002 · Principle
- Journey MapTPL·004 · Template
- Product SpecificationTPL·011 · Template
- MiroTOOL·007 · Tool
- DiscoveryFLOW·004 · Workflow
- Prioritising Design WorkFLOW·006 · Workflow
Short definition
The one-paragraph version, for when that is all you need.
- Minimum Lovable ProductTERM·092 · Term
- Minimum Viable ProductTERM·091 · Term
- User StoryTERM·094 · Term