Story Mapping

User Story Mapping Expert

Overview

Visualize the user journey and translate strategy into prioritized, deliverable work using Jeff Patton's user story mapping technique. Story maps shift teams from feature-first thinking to flow-first thinking -- understanding the complete user experience before deciding what to build and in what order.

A story map is a 2D grid: the backbone (activities → steps) runs left-to-right in the order users experience the journey, the body (tasks) hangs below each step ranked top-to-bottom by priority, and a horizontal MVP line separates Release 1 from later. See the playbook reference for full anatomy and the 6-step build sequence.

When to Use

• MVP definition -- Draw a clear line between "must ship" and "can wait."
• Release planning -- Sequence work across multiple releases or sprints.
• Cross-team alignment -- Give multiple teams a shared understanding of the user journey.
• Backlog reorganization -- Restore context and priority to a flat backlog.
• New product kickoff -- Decompose a vision into work from scratch.

When NOT to Use

• Purely technical infrastructure work with no user journey (use technical spikes).
• The team already has a well-prioritized, context-rich backlog.
• Single-feature work that doesn't span multiple user activities.

Clarify First

Before building the map, confirm these inputs. If any is unknown or vague, ASK — do not assume:

• [ ] The user and their end-to-end journey — who travels it and the activities → steps in order (defines the backbone, the left-to-right spine of the map)
• [ ] The target release / MVP — what must ship first vs can wait (sets where the MVP line is drawn between Release 1 and later)
• [ ] The map's goal — MVP definition vs release sequencing vs cross-team alignment (changes how the body tasks are sliced and prioritized)

Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.

References

• [references/playbook.md](references/playbook.md) — read this when building a map: story-map anatomy, the 6-step build sequence, the artifact template, map patterns (walking skeleton / thick slice / progressive enhancement), the workshop facilitation guide, troubleshooting, and success criteria.
• [references/red-flags.md](references/red-flags.md) — read this before using a map for release planning: common ways a story map goes wrong with bad/good quoted examples and fixes.

Scope & Limitations

In Scope: User story map creation, backbone and body decomposition, release slice definition, MVP scoping, facilitation guidance, workshop planning, template and pattern library.

Out of Scope: Individual story writing and acceptance criteria (see job-stories/ or agile-product-owner), technical architecture decisions, detailed effort estimation, sprint planning mechanics.

Important Caveats: Story maps are planning tools, not contracts. They should be updated as the team learns. A map created before building will always be wrong in details -- the value is in the shared understanding, not the artifact itself. Jeff Patton: "The map is not the territory; the conversation is the territory."

Integration Points

Further Reading

• Jeff Patton, User Story Mapping (2014)
• Jeff Patton, "The New User Story Backlog Is a Map" (2005)
• Inspired by Productside story mapping workshops

Example: Story Map for Wayfinder Mobile App Onboarding

Real-world scenario showing how to apply this skill end-to-end.

Context

Wayfinder (travel-tech, Series B) is launching a mobile app for tour operators' field guides. The app's most-critical journey is onboarding -- a new field guide downloads, signs in, downloads tour data offline, and runs a tour without WiFi. The PM (Liana) is using a Jeff Patton-style user story map to scope MVP, v1.1, and v1.2 releases for the design partner cohort.

Without a story map, the team has been arguing about whether biometric login is "MVP" since week one. The map will end the argument by visualizing the full user backbone, mapping all candidate stories underneath, then drawing release lines that say: this slice gets to the moment of value.

Inputs

• Single user persona: "Field guide" -- a tour operator's contractor who runs day tours on a mobile device
• Constraint: must work offline for a full 8-hour tour
• Three releases planned: MVP (Aug 2026), v1.1 (Oct 2026), v1.2 (Dec 2026)
• Design partner cohort: 12 tour operators
• Goal: by v1.2, 80% of field guides at design-partner operators run all tours from the mobile app

Applying the skill

1. Define the backbone (user activities, left to right). What does a field guide do, in order? Five activities: get the app, sign in, prep for a tour, run the tour, wrap up. 2. Decompose each activity into user tasks. Each task is a verb-noun the user does ("download offline data," "check guest list"). 3. Map candidate stories under each task. Stories are the concrete implementation slices. 4. Draw the first release line (MVP) above the minimum stories that get the user from "get the app" to "run the tour" once. 5. Draw v1.1 and v1.2 above subsequent layers of richness. 6. Confirm by walking the map -- can the user actually complete a tour with only the MVP stories? If not, raise the line.

The artifact

Story map (Mermaid)

graph TD
    subgraph BACKBONE["User backbone -- a field guide's day"]
        A1[1. Get the app]
        A2[2. Sign in]
        A3[3. Prep for a tour]
        A4[4. Run the tour]
        A5[5. Wrap up]
    end

    A1 --> T1A[Find app in store]
    A1 --> T1B[Install + open]

    A2 --> T2A[Email login]
    A2 --> T2B[Stay signed in]

    A3 --> T3A[See today's tours]
    A3 --> T3B[Download tour data offline]
    A3 --> T3C[See guest manifest]

    A4 --> T4A[Mark guests present]
    A4 --> T4B[Open stop details]
    A4 --> T4C[Mark stops complete]
    A4 --> T4D[Capture issues]

    A5 --> T5A[Submit completed tour]
    A5 --> T5B[See tomorrow's tours]

    style BACKBONE fill:#fde68a,stroke:#333

Stories under each task (full grid)

Release-line walkthrough

MVP (Aug 2026): "Can a field guide download an app, sign in via magic link, download tour data offline, run an 8-hour tour with no signal, then auto-sync when WiFi comes back?"

Walking the MVP row left to right:

• Find app in store -> install -> magic-link login -> see today's tours -> download tour offline -> see manifest -> mark guests present -> open stop details -> mark stops complete -> capture issue offline -> tour ends -> walk back to WiFi -> tour auto-syncs -> done.

Yes. MVP completes the journey once.

v1.1 (Oct 2026): Adds the things field guides told us would save them 5+ minutes per tour:

• Background pre-download (do not need to remember the night before)
• Audio guide playback (stops feel richer)
• Geofence auto-complete (one less tap per stop)
• Manifest search (find a guest fast when group is 30 people)

v1.2 (Dec 2026): Adds the things tour operators told us would unlock training and quality:

• Biometric login (a tour-day usability win)
• SSO (tour operator IT can manage)
• AR overlays at landmarks (the demo-able differentiator)
• Tomorrow + day-after preview (lets the guide prep better)

What is explicitly out of scope (no release line)

• In-app booking / payment (this is for guides, not guests)
• Multi-language UI beyond English/Spanish (Q1 2027)
• Tablet-specific layout (iPad will work in scale mode -- not a redesign)
• Apple Watch companion (someone always asks; the answer is no, not now)

Validation cohorts per release

Sketch -- the story map on the whiteboard

                    1. GET APP    2. SIGN IN     3. PREP        4. RUN TOUR        5. WRAP UP
                    -----------   -----------    ------------   ----------------   --------------
BACKBONE            find/install  email login    see tours      mark guests        submit tour
                                  stay-signed    download tour  open stops         see tomorrow
                                                 guest manifest mark complete
                                                                capture issues

----- MVP line -----
MVP STORIES         app in store  magic link     list tours     present (tap)      auto-sync on
                    install       30-day token   download btn   stop details       WiFi
                                                 manifest list  mark complete
                                                                free-text issue

----- v1.1 line -----
v1.1 STORIES        skeleton      password+      pull-refresh   bulk all-present   manual submit
                    screens       email          background     audio guide        tomorrow list
                                                 pre-download   geofence auto
                                                 sync stamp     manifest search
                                                                photo attach

----- v1.2 line -----
v1.2 STORIES        update        biometric +    smart partial  photo capture      pre-flight
                    banner        SSO            sync           AR overlays        validation
                                                 day-after view bulk complete      calendar
                                                 guest photos   categorized issues

Why this works

• The backbone (5 user activities) is genuinely the journey, not a feature taxonomy. Reading it left-to-right tells a story.
• The MVP release line is drawn after the team walked the map together. The walk caught two missing stories ("issue capture" was below the line in the first draft, but field guides need to log issues offline -- it had to come up).
• Biometric login was the big argument going in. The map puts it in v1.2 with a defensible reason -- magic link unblocks MVP, biometric adds polish later -- and the argument stopped.
• Out-of-scope items are written down. "Apple Watch companion: no, not now" is a sentence the team can point to.
• Each release has a validation cohort. The map is not a launch plan -- it is a learning plan.

What's next

• Convert each MVP story to a backlog item via ../story-splitting/ (some stories are too big).
• Write the PRD for the MVP slice using ../create-prd/.
• Convert stories to WWAS / Why-What-Acceptance format via ../wwas/.
• Plan the design-partner rollout via ../beta-program/.
• Track release readiness via ../status-update-generator/.

Story Mapping Playbook

Read this when you need the full story-map mechanics: anatomy, the 6-step build sequence, the artifact template, map patterns, the workshop facilitation guide, troubleshooting, and success criteria.

Story Map Anatomy

A story map has three layers arranged in a 2D grid:

                    USER JOURNEY (left to right) →
                    
    ┌──────────────────────────────────────────────────┐
    │  Activities    Activity 1    Activity 2    Act 3  │  ← Backbone
    ├──────────────────────────────────────────────────┤
    │  Steps         Step 1.1      Step 2.1     Step   │  ← Backbone
    │                Step 1.2      Step 2.2      3.1   │
    ├──────────────────────────────────────────────────┤
    │  Tasks         Task A        Task D       Task G │  ← Body
    │  (Release 1)   Task B        Task E              │  ← MVP line
    │  ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │
    │  Tasks         Task C        Task F       Task H │  ← Body
    │  (Release 2)                                     │  ← Follow-up
    └──────────────────────────────────────────────────┘
    
    PRIORITY (top to bottom) ↓

Key Principle: Flow First, Then Priority

• Horizontal axis (left to right): The user's journey through time -- activities and steps in the order users experience them.
• Vertical axis (top to bottom): Priority -- most critical tasks at the top, nice-to-haves at the bottom.
• MVP line: A horizontal line drawn across the map separating "Release 1" from "Later."

Building a Story Map

Step 1: Define Who and What

Step 2: Map the Backbone (Activities)

Walk through the user's journey and identify 3-7 high-level activities:

#### Activities:
1. [Discover the product]
2. [Sign up and onboard]
3. [Complete core task]
4. [Review results]
5. [Share with team]

Tips:

• Use active verbs ("Discover," "Configure," "Review") not nouns.
• Keep to 3-7 activities -- more means you need to zoom out.
• Arrange left to right in the order users experience them.

Step 3: Break Activities into Steps

For each activity, identify 3-5 sequential steps:

#### Steps for "Sign up and onboard":
- Step 1: Create account
- Step 2: Verify email
- Step 3: Set up profile
- Step 4: Complete tutorial
- Step 5: Invite team members

Step 4: Decompose Steps into Tasks

For each step, list specific implementation tasks:

#### Tasks for "Create account":
- Email/password registration
- Social login (Google, GitHub)
- SSO integration
- Terms acceptance
- Password strength validation

Step 5: Prioritize Vertically

Arrange tasks within each column from top (highest priority) to bottom (lowest):

• Top: Must-have for the journey to work at all.
• Middle: Important for a good experience.
• Bottom: Nice-to-have, can defer.

Step 6: Draw Release Lines

Draw horizontal lines across the map to define releases:

═══════════════════════════ Release 1 (MVP) ═══════════
- Email/password registration
- Verify email
- Basic profile setup
- Core task (minimal)
- View results

═══════════════════════════ Release 2 ═══════════════════
- Social login
- Team invitations
- Advanced tutorial
- Share results
- Export results

═══════════════════════════ Release 3 (Polish) ══════════
- SSO integration
- Custom branding
- Advanced analytics
- API access

Story Map Template

## User Story Map

### Context
- **Segment:** [Target segment]
- **Persona:** [Persona name and key characteristics]
- **Narrative:** [The job or goal being mapped]
- **Decision:** [What this map informs]

### Backbone

#### Activities:
1. [Activity 1]
2. [Activity 2]
3. [Activity 3]
4. [Activity 4]
5. [Activity 5]

#### Steps:
**[Activity 1]:**
- Step 1: [Description]
- Step 2: [Description]
- Step 3: [Description]

**[Activity 2]:**
- Step 1: [Description]
- Step 2: [Description]
- Step 3: [Description]

[Continue for each activity]

#### Tasks:
**[Activity 1, Step 1]:**
- Task 1: [Description]
- Task 2: [Description]
- Task 3: [Description]

[Continue for each step]

### Release Slices

**Release 1 (MVP):**
- [Task list -- minimum viable journey]

**Release 2:**
- [Task list -- improved experience]

**Release 3:**
- [Task list -- full vision]

### Assumptions to Validate
- [Assumption 1]
- [Assumption 2]
- [Assumption 3]

### Risks and Dependencies
- [Risk or dependency 1]
- [Risk or dependency 2]

Common Story Map Patterns

Pattern 1: Walking Skeleton

Map the thinnest possible end-to-end journey first:

Activity 1 → Activity 2 → Activity 3 → Activity 4
    ↓             ↓             ↓             ↓
  1 task        1 task        1 task        1 task

One task per activity, proving the full flow works. Then add depth.

Pattern 2: Thick Slice

When one activity is the core value, go deep there first:

Activity 1 → Activity 2 → Activity 3 → Activity 4
    ↓             ↓             ↓             ↓
  1 task        5 tasks       1 task        1 task
                (core)

Pattern 3: Progressive Enhancement

Layer capabilities across releases:

Release 1:  Basic flow    (all activities, minimum tasks)
Release 2:  Error handling (edge cases, validation)
Release 3:  Power features (automation, customization)
Release 4:  Scale          (performance, enterprise)

Facilitation Guide

Running a Story Mapping Workshop

Total: ~100 minutes for a focused session.

Materials: Sticky notes (3 colors: activities, steps, tasks), markers, large wall or whiteboard, or Miro/FigJam for remote.

Key facilitation rules:

• Keep each sticky note to 4-8 words.
• Activities and steps first; resist jumping to tasks.
• Everyone writes, not just the PM.
• Debate the MVP line, not individual task priority.

Integration with Other Skills

• Use job-stories/ JTBD discovery canvas to define the narrative before mapping.
• Feed Release 1 tasks into create-prd/ for detailed requirements.
• Use prioritization-frameworks/ RICE scoring to prioritize within release slices.
• Use brainstorm-okrs/ to align release slices with quarterly objectives.
• Convert tasks into user stories or job stories using job-stories/ or wwas/.

Troubleshooting

Success Criteria

• Story map covers one persona and one narrative end-to-end
• 3-7 activities spanning the complete user journey
• Each activity has 3-5 observable steps
• MVP line drawn with team consensus
• Release 1 (MVP) is a complete walking skeleton -- every activity has at least one task
• All tasks are independently deliverable (pass INVEST criteria)
• Map reviewed and updated at sprint boundaries

Red Flags: Story Mapping

Common ways this skill's output goes wrong -- concrete examples, why they're bad, and how to fix them.

How to use this document

Scan every story map before using it for release planning. Each red flag has bad and good quoted examples.

---

Red Flag 1: Map-as-Gantt

Symptom. The "story map" is a horizontal timeline with dates and dependencies. Cards are stacked left-to-right in delivery order. Why it's bad. A story map is a 2D model of the user journey with a release-slice axis. A Gantt is a delivery plan. Conflating them loses the customer narrative -- the map shows when work happens, not what experience users will have. Releases become arbitrary date cuts, not coherent user journeys. Bad example:

"[Horizontal timeline]:

Sprint 1: stories A, B, C.

Sprint 2: stories D, E, F.

...

(No journey backbone, no customer activities, just sprints.)"

Good example:

"[Story map with two axes]:

Backbone (left to right, customer journey): Discover -> Sign up -> Activate -> Use daily -> Pay -> Upgrade.

Slices (top to bottom, releases): R1 (walking skeleton across the journey), R2 (richer activation), R3 (upgrade flow).

Each card sits at a (journey-step, release) coordinate."

How to catch it. No customer-journey backbone label across the top = not a story map.

---

Red Flag 2: Missing the Customer Journey Backbone

Symptom. Map starts directly with stories grouped by feature area ("Auth", "Search", "Settings"), no user activities at the top. Why it's bad. Feature-area grouping is a system view, not a user view. The whole point of Patton's story mapping is to keep the customer journey visible so the team can spot gaps and prioritize end-to-end value. Without the backbone, the map devolves into a categorized backlog. Bad example:

"Top of map: Auth | Search | Settings | Notifications | Admin.

(These are system buckets, not user activities.)"

Good example:

"Top of map (customer journey backbone): Find a candidate -> Schedule interview -> Conduct interview -> Send offer -> Onboard hire.

Cards underneath each activity describe what the user does (e.g. 'filter candidates by skill', 'add interview panel', 'send offer letter'). System areas are tags on cards, not the backbone."

How to catch it. Backbone columns are nouns (system areas) instead of verbs (user activities) = rewrite the backbone.

---

Red Flag 3: Walking Skeleton Skipped

Symptom. First release slice contains 100% of the activation flow polish but only 50% of the journey -- payment and upgrade flows are not present at all. Why it's bad. The walking skeleton (R1) should be the thinnest possible end-to-end vertical slice that covers the entire journey, even if each step is minimal. Skipping it means R1 ships a half-product that does not deliver end-to-end value; users cannot complete a real workflow. Bad example:

"R1: 18 stories under Sign-up + Activate. R2 promised to add Pay and Upgrade.

(Users cannot pay in R1.)"

Good example:

"R1 (walking skeleton): 1-3 stories per backbone step covering the full journey end-to-end. Sign-up flow is functional but minimal. Activate has 1 path. Pay accepts one method. Upgrade exists but only manual.

R2: enrich the steps where data shows friction."

How to catch it. R1 has zero stories under one or more backbone columns = no walking skeleton.

---

Red Flag 4: Personas Mixed in One Map

Symptom. A single map mixes the recruiter journey, the candidate journey, and the admin journey in one set of columns. Why it's bad. Different personas have different journeys with different rhythms. Mashing them creates incoherent backbones ("recruiter signs up -> candidate gets email -> admin sets permissions"), and stories cannot be released coherently. Cross-persona dependencies become invisible. Bad example:

"Backbone: Sign-up | Schedule | Take interview | Review | Send offer.

(Mixing recruiter and candidate activities in one row.)"

Good example:

"Three story maps, one per persona:

- Recruiter map: Find candidate -> Schedule interview -> Send offer.

- Candidate map: Receive invite -> Take interview -> Receive decision.

- Admin map: Set roles -> Configure templates -> Audit usage.

Cross-persona dependencies marked with arrows between maps."

How to catch it. Single map has cards owned by different personas in the same backbone column = split.

---

Red Flag 5: Stories That Are Implementation Tasks

Symptom. Cards say "set up the database schema", "configure Kubernetes", "write API endpoint" -- engineering tasks, not user stories. Why it's bad. The map is a user-experience artifact. Implementation tasks belong in tickets, not on the map. Mixing them obscures the user journey and confuses prioritization (you cannot meaningfully release "set up Kubernetes" to a user). Bad example:

"Cards under 'Sign up': set up Postgres, configure Auth0, write /users API endpoint, deploy to staging."

Good example:

"Cards under 'Sign up': enter email and password, verify via email link, set up profile, choose plan.

(Implementation tasks live as sub-tickets in Jira, not on the map.)"

How to catch it. Card content describes systems / infrastructure / code, not user actions = rewrite as a user story.

---

Red Flag 6: Map Becomes a Static Wall Decoration

Symptom. The map was created at the start of the project and has not been touched in 4 months. Why it's bad. A map is a thinking tool, not a deliverable. If it does not evolve as the team learns, it lies -- showing a plan that no longer matches reality. New team members read it as truth and waste time aligning to the wrong picture. Bad example:

"Map last updated: January. Today: May. R1 shipped in March; R2 in progress; nothing on the map reflects this."

Good example:

"Map updated weekly in the backlog refinement session: stories moved from Up Next to In Progress to Done; new stories added based on user research; releases re-sliced based on what we learned. Snapshots committed to git per release."

How to catch it. Map's last edit > 3 weeks ago = map is dead.

---

Red Flag 7: No Release Slicing Strategy

Symptom. Cards are listed under journey steps but there are no horizontal lines or labels showing R1 / R2 / R3. Why it's bad. The second axis of the map is the whole point -- it forces the team to decide what is in this release vs. later. Without it, the map is just a categorized backlog, and the team ends up releasing whatever happens to be done. Bad example:

"Map shows 200 cards under the journey backbone. No release slicing."

Good example:

"Map shows 200 cards. Horizontal slice 1 (R1, walking skeleton): 32 cards, ships end of Q2. Slice 2 (R2, depth in activation): 48 cards, Q3. Slice 3 (R3, enterprise journey): 60 cards, Q4. Remaining 60 unsliced (future)."

How to catch it. No release labels on the vertical axis = add them.

---

Red Flag 8: Mapping a Solution, Not a Problem

Symptom. The map describes the team's planned product, not the user's actual current journey. Why it's bad. Story mapping is most powerful when it surfaces the gap between the current user journey (with all its workarounds) and the future product. Mapping only the proposed solution skips the diagnostic step and means the team builds without seeing where users today get stuck. Bad example:

"Map shows the new product's flow: sign up -> create dashboard -> share -> upgrade. No mention of how users do this today (e.g. in spreadsheets)."

Good example:

"Two-state map:

- Top row: current user journey (with workarounds, friction points marked in red).

- Bottom row: future product journey (same backbone, redesigned).

The gaps between top and bottom are the team's bets."

How to catch it. Map only shows the future state = add the current-state row before slicing releases.

---

Red Flag 9: Cards Without Acceptance Criteria

Symptom. The map has user-friendly cards ("filter candidates by skill") but no acceptance criteria, INVEST checks, or testable behavior. Why it's bad. A story map is the planning artifact; cards eventually become stories that need to be testable. Treating the map as the final form means stories enter sprints under-defined, get extended mid-sprint, and the slicing collapses. Bad example:

"Card: 'filter candidates by skill'.

Sprint starts; team realizes there are 4 interpretations; story splits into 3 mid-sprint."

Good example:

"Card: 'filter candidates by skill'.

When the card moves from the map into a sprint, it gets enriched (see backlog-refinement skill): persona, scenario, acceptance criteria (Given/When/Then), INVEST check. The map keeps the short card form for the journey view."

How to catch it. Stories pulled into a sprint without enrichment = link map to backlog-refinement skill.

---

Red Flag 10: One-Person Map

Symptom. The PM built the map alone and is now presenting it to the team. Why it's bad. The value of story mapping is the building -- the shared understanding that emerges when PM, design, and engineering co-create. A one-person map is a delivery document, missing the assumptions challenge, the technical-feasibility input, and the design alternatives. Bad example:

"PM spent the weekend building the map. Presenting it Monday for team review."

Good example:

"Map built in a 3-hour workshop: PM, design lead, eng lead, customer-success rep. Each persona's journey researched ahead of time (interview-synthesis outputs). Map exits with shared understanding, surfaced assumptions logged separately."

How to catch it. Map has a single author = re-do as a workshop.

---

Red Flag Quick Reference

Related Reading

• SKILL.md -- Patton's user story mapping
• references/mapping-patterns.md -- backbone / slice / walking-skeleton patterns
• Sibling skill: discovery/interview-synthesis/ -- the customer-journey research that feeds the backbone
• Sibling skill: execution/backlog-refinement/ -- enrich map cards into INVEST stories
• Sibling skill: execution/story-splitting/ -- vertical-slice patterns for over-large cards
• Sibling skill: execution/outcome-roadmap/ -- map fits between roadmap and refined backlog