Complete firstPersonas
At least one persona or clear user understanding exists to orient backbone activities.
Without: Without user clarity, the map drifts into feature lists without user perspective and cannot produce meaningful release slices.
RunsheetProduct Discovery
User Story Mapping
ComplexityMedium
Time2-4 h
Participants4-10
FormatWorkshop
MaturityCanonical
01
Prerequisite
What needs to be finished first
Complete firstProduct Vision Board
A product or release vision with clear outcome exists so slices can be evaluated against it.
Without: Without vision, all stories become equally important and the map cannot separate MVP slice from later slices.
02
Preparation
What needs to be ready before start
Materials
Long wall or Miro board with horizontal lanes; four sticky colors (yellow activities, blue tasks, green stories, pink risks); wide tables for sorting; timer; link to existing backlog if available.
People / roles
One facilitator with mapping experience; Product Owner; two to four engineers; UX lead; optional stakeholder from sales or support. Maximum eight people, otherwise flow breaks down.
Pre-read
User persona; outcome hypothesis of product or release; known constraints (compliance, platform, dates); existing backlog as input, not as directive.
Time needed
4-6 h for first map, then 1 h maintenance per release
Setup
Prepare wall: persona top left, then timeline for user activities from left to right (backbone). Lane below for tasks, below that lane for stories. Right wall for later parking lot.
03
Core question
The one question this method answers
Which narrowest end-to-end flow delivers the first real value to the user, and what is the next meaningful slice after that?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Build backbone | 45-60 min | Collect user activities chronologically (yellow), at rough granularity: what does the user do from start to goal. Then order and condense to 8-15 backbone steps. | If backbone has more than 20 steps, level is too fine. Activities are not clicks, but tasks ("place order", not "press button"). |
2Phase 2: Tasks and stories | 60-90 min | For each activity, place required tasks (blue) and concrete stories (green) below it. Stories as small outcome steps, several possible per task. | Do not formulate stories as implementation-heavy. If a story is technology-specific ("implement with React"), it belongs in tasks, not in the map. |
3Phase 3: Mark risks | 20-30 min | Place pink stickers on stories with high uncertainty or dependency. Briefly note what endangers the slice (technical, regulatory, user-side). | If all stories are pink, the map is too early. Run discovery methods first, then map. Mark only truly critical risks. |
4Phase 4: Cut slices | 45-60 min | Draw horizontal lines across the map: first line for MVP (narrowest flow that delivers real value), second for Release 2 etc. Stories above the line are in, below are out. | MVP slice must pass through every backbone activity, otherwise it is not end-to-end. Prefer less depth per step over omitting whole steps. |
5Phase 5: Validate and hand over | 30-45 min | Check MVP slice against user persona and vision. Can the persona do their job? Move slice stories into backlog with estimate size and owner. | If the persona cannot do their job with the MVP slice, it is not an MVP but a fragment. Recut slice before filling backlog. |
05
Artifact
What comes out at the end
Form
Story map as photo or Miro board with backbone, tasks, stories, risks, and release slices. Supporting mapping doc with persona, outcome hypothesis, MVP definition, slice list, and open risks.
Versioning / ownership
Store map per release as own snapshot. Link backlog stories with map ID. Change backbone only through mapping session, not silently in ticket system.
Tool alternatives
- Miro or Mural Story Map template
- Avion or StoriesOnBoard as dedicated tool
- Whiteboard with photo snapshot in Confluence
- Jira/Linear with epics as backbone and stories below
user-story-mapping-working-template.md
Compact working template for User Story Mapping with context, input, output artifacts, and next step.
User Story Mapping Canvas
Context
What is this method used for?
Core question
Which question should be answered at the end?
Input
Which data, observations, or materials are available?
Working area
- Area 1:
- Area 2:
- Area 3:
- Relationships / patterns:
Output artifacts
- Story map:
- Release slices:
- Backlog candidates:
Open questions
- ...
Next step
Owner, date, success signal.
06
Example output
Concrete filled scenario, fictional example
user-story-mapping-beispiel.md
Concrete filled scenario, fictional example
Story Map - Onboarding redesign, May 2026
Persona: New SaaS user (solo founder, non-technical background). Outcome: 60% of new users reach aha moment in session 1 (today 28%).
Backbone: Register -> Create workspace -> Import first project -> See first insight -> Invite team.
MVP slice (Release 1, by 2026-06-30):
- Register: magic link instead of password.
- Create workspace: one default template, no wizard.
- First project: CSV upload, max 3-column auto-detection.
- First insight: one predefined top-3 visualization.
- Invite team: by email address, no role system.
Release 2 (by 2026-07-31):
- Google/Microsoft SSO.
- Wizard for complex data sources.
- Several visualizations selectable.
- Role permissions for invitees.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Backbone becomes feature list
Symptom
Top row contains names like "Dashboard" or "Export module", not user activities.
What to do
Ask: what does the user do here. Formulate backbone card with verb. Feature names belong in tasks or stories below.
Trap
MVP slice is a layer, not end-to-end
Symptom
Slice only covers registration and workspace, user cannot finish their job.
What to do
MVP must pass through every backbone activity, each one thinly. Better two cards per activity than all cards of the first two activities.
Trap
Map outdated after 4 weeks
Symptom
Backlog evolves in ticket system, map is no longer updated.
What to do
Define map as source of truth for scope decisions; backlog mirrors it. Fixed mapping session every 2-4 weeks.
Trap
Too much detail
Symptom
Map contains 300+ stickies, overview is lost.
What to do
Consolidate tasks and stories. Hard-limit backbone to max 15 steps. Detail belongs in refinement, not in the map.
Trap
Stakeholders missing during slicing
Symptom
PO slices alone, engineering not involved, effort unrealistic.
What to do
Run slicing only with engineering. Estimate rough T-shirt size per slice together. If engineering unavailable, postpone phase 4.
Trap
Vision missing or changing
Symptom
Discussion circles around what the team wants to achieve, map is rebuilt repeatedly.
What to do
Set binding vision/outcome hypothesis before mapping. If unclear, run Product Vision Board first.
08
Stop criteria
Done signals checkable in under a minute
No persona or clear user understanding available, backbone becomes feature list.
Product vision or outcome hypothesis missing, MVP cut cannot be decided.
No engineering present, slice effort remains speculative.
Scope covers several disjoint personas or products, one map cannot carry both.
Fixed prioritized feature set already imposed externally, mapping creates theater documentation.
Discovery state too uncertain, more than half of stories are research spikes.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.