01 / UNDERSTAND
What is a user story map?
A user story map organises work around the activities and tasks a person performs to reach a goal. The horizontal narrative preserves the experience while details and alternatives sit beneath it. A release slice should support a meaningful outcome, rather than collect unrelated high priority features. The map is a conversation aid, not a substitute for understanding users.
Why use User Story Map?
A flat backlog makes individual requests visible while hiding how they work together. A story map helps a team discuss the whole activity, identify missing tasks and choose a coherent scope for learning or delivery. It also makes a proposed cut easier to challenge: what can the person actually accomplish with this slice?
When to use it
USE IT WHEN
A backlog needs to be connected to the user’s activity.
The team must choose a coherent initial release or experiment.
Important tasks or exceptions are lost between separate feature discussions.
When to choose another method
Use Customer Journey Map to understand the wider experience and its evidence.
Use Service Blueprint when delivery dependencies behind the interaction are the primary question.
Do not use story mapping to make an unresearched feature list appear user centred.
What you’ll need
Choose a user, goal and scenario. Bring research, known constraints and people who understand delivery. Prepare activity and task labels as short verbs rather than interface names. State whether the map describes current behaviour or a proposed product. Keep assumptions and exceptions visible while discussing possible release boundaries.
What the method needs
Keep the elements that help answer your question and support a decision.
Who should accomplish what in the scenario.
The broad narrative of the work.
Actions that make each activity possible.
Variations, exceptions and implementation conversations.
Coherent sets of work tied to an outcome or learning goal.
Evidence needed to check scope, usefulness and delivery.
02 / PUT IT INTO PRACTICE
How to create a user story map
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Tell the story
Walk through a concrete scenario from start to outcome.
A learner finds, books and prepares for an evening course.
02
Build the backbone
Group the narrative into meaningful activities.
Choose a course, enrol and prepare.
03
Add tasks
Place actions under the relevant activity.
Check prerequisites, select a session and receive joining instructions.
04
Explore alternatives
Include exceptions that change whether the outcome is possible.
A course fills up or a learner needs access support.
05
Slice for an outcome
Choose a coherent route instead of isolated features.
An initial supported booking must still produce usable joining information.
06
Check and plan
Validate assumptions and expose delivery dependencies.
Verify how staff send instructions before promising the first release.
Example: a first course booking release
Illustrative scope, not an approved roadmap. A team maps choosing, enrolling and preparing for a course. The proposed first release offers a small course set, a booking request and staff assisted confirmation.
The slice also needs a way to communicate joining instructions and handle a full session. Removing these because they seem less prominent would leave a booking that cannot reliably become attendance. The team checks the assisted workload and tests the complete route. Later automation remains below the release line rather than being confused with a missing user outcome.
03 / BELOW THE SURFACE
Below the surface: a thin slice can hide a thick manual service
A small digital release may work only because staff bridge its gaps. Make that support explicit. Record who performs it, what information they need and how the team knows a request has been completed.
01 / EVIDENCE
What is supported?
Which source or observation supports the current interpretation?
02 / LIMIT
What remains uncertain?
Which assumption would change the decision if it were wrong?
03 / ACTION
What happens next?
Who will investigate or test the next step, and when?
Manual support can be a deliberate learning choice, but it should not disappear from the release discussion. Ask whether the proposed volume, access needs and failure cases remain manageable. If the team cannot support the whole route, narrow the scenario rather than silently dropping the ending. This is an editorial scope check, not a rule that an initial release must automate everything.
User Story Map template
Use the first page for the practical work and the second to challenge the reasoning before choosing a next step. The canvas follows this guide and keeps evidence, assumptions and decisions visible.
The two page PDF contains 27 editable fields. Open it in a PDF reader that supports forms and save a working copy.
Practical tips
Use verbs to keep tasks distinct from interface components.
Name the outcome of each proposed slice.
Show important exceptions before agreeing the boundary.
Common mistakes
Turning a feature list sideways and calling it a story.
Selecting only the top item in each column without checking the route.
Ignoring staff work that makes the first release possible.
What you’ll get
A coherent release slice and its delivery assumptions. Keep the supporting evidence and unresolved questions with the output. Assign an owner to the next action and revisit the result when the underlying situation changes. The method supports judgement; the completed canvas is not proof that the proposed choice will work.