# User Story Mapping — From User Goals to Interface

<!-- hint:slides topic="User story mapping: backbone and body, walking skeleton, release slicing, and workshop facilitation" slides="5" -->

## What Is Story Mapping?

User story mapping is a collaborative technique for organizing user stories into a visual map that reflects the user's journey. It helps teams see the big picture, prioritize work, and slice releases that deliver value incrementally. Jeff Patton popularized the method in *User Story Mapping*.

## Why It Works

- **User-centered** — The map is organized by user activities, not features or technical components.
- **Visual** — A 2D map (backbone + body) makes scope and sequence obvious.
- **Release-ready** — Horizontal slices create coherent releases; vertical slices create thin end-to-end flows.
- **Conversation starter** — The map fuels discussion about goals, constraints, and tradeoffs.

## The Backbone vs The Body

The map has two main parts:

| Part | What It Is | Example (E‑commerce) |
|------|------------|----------------------|
| **Backbone** | High-level user activities (left-to-right, top row) | Browse → Add to cart → Check out → Track order |
| **Body** | User tasks under each activity (stacked below) | Under "Check out": Enter shipping, Choose payment, Review order, Confirm |

```mermaid
flowchart LR
    subgraph Backbone
        A[Browse] --> B[Add to Cart]
        B --> C[Check Out]
        C --> D[Track Order]
    end
    subgraph Body["Body (tasks under each activity)"]
        E[Search / Filter]
        F[View product]
        G[Add to cart]
        H[Enter shipping]
        I[Choose payment]
        J[Confirm]
    end
```

## Walking the User's Journey

To build the map:

1. **Identify the user** — Who is this map for? (e.g., new shopper, returning customer)
2. **List activities** — What do they do at a high level? (Use verbs: browse, compare, buy)
3. **Add tasks** — Under each activity, break it into specific tasks. "Check out" → Enter address, Select shipping, Enter payment, Review, Confirm.
4. **Order left-to-right** — Activities and tasks follow the natural sequence of the user's journey.
5. **Walk the map** — Read it like a story. Does it make sense? What's missing?

## Slicing Releases: Walking Skeleton

A **walking skeleton** is the thinnest end-to-end path that delivers value. You slice horizontally:

- **Release 1 (MVP)** — One path through the map: minimal tasks to complete the journey.
- **Release 2** — Add the next most important tasks or variations.
- **Release 3+** — Expand functionality, edge cases, optimizations.

```mermaid
flowchart TD
    subgraph Map["Story Map"]
        B1[Browse - basic]
        B2[Add to cart]
        C1[Check out - minimal]
        C2[Payment - one option]
    end
    subgraph R1["Release 1: Walking Skeleton"]
        R1A[Browse] --> R1B[Add]
        R1B --> R1C[Checkout]
    end
    subgraph R2["Release 2"]
        R2A[More browse]
        R2B[Multiple payment]
    end
```

## From Map to MVP

1. **Identify the outcome** — What does the user accomplish? (e.g., "Purchase a product")
2. **Find the critical path** — The minimum tasks needed to reach that outcome.
3. **Slice Release 1** — Those tasks become your MVP. Everything else is "later."
4. **Write acceptance criteria** — For each story in the slice, define "done."

## Story Mapping Workshops

**How to run one:**

1. **Prep** — Define the user and outcome. Bring sticky notes (digital or physical).
2. **Activities** — As a group, brainstorm activities. Place them left-to-right.
3. **Tasks** — Under each activity, add tasks. Encourage "that's too big—break it down."
4. **Prioritize** — Vote or discuss. Move the most important tasks to the top of each column.
5. **Slice** — Draw a line: above = Release 1, below = later.
6. **Commit** — Capture the map and release boundaries. Treat it as a living artifact.

**Tip:** Include developers, designers, and product. The conversation matters more than the map.

## Connecting Stories to Acceptance Criteria

Each task on the map can become one or more user stories:

```
As a [user], I want to [task] so that [outcome].
```

Acceptance criteria answer: "How do we know it's done?"

- **Given** [context], **When** [action], **Then** [expected result]
- Or: a short checklist of conditions that must be true

## Common Mistakes

| Mistake | Fix |
|---------|-----|
| **Too granular too early** | Start with activities and a few tasks. Add detail when slicing. |
| **Forgetting the user goal** | Always tie the map to a specific user and outcome. |
| **Activities = features** | Activities are user actions (e.g., "Compare products"), not system features. |
| **Skipping the walk** | Read the map as a story. Gaps and odd ordering will appear. |
| **One map for everyone** | Different users have different journeys. Create separate maps if needed. |

## Summary

User story mapping turns user goals into a visual journey: backbone (activities) + body (tasks). Slice horizontally for releases; start with a walking skeleton. Run workshops, walk the map, and connect tasks to user stories with acceptance criteria. The map is a living artifact—update it as you learn.