# User Story Map: [Product or feature name]

> User story map following the story mapping technique described by Jeff
> Patton in *User Story Mapping*. The backbone of user activities runs left
> to right in the order users experience them; stories hang below each
> task, and horizontal slices define releases, starting with a walking
> skeleton. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- Build the map with the team and stakeholders in one room (or one shared
  board), then record the result here. The conversation is the point; this
  file is the memory of it.
- Tell the story left to right first: what does the user do, step by step?
  Only then add detail and alternatives below each step.
- Slice horizontally by outcome, not by component. Each release slice must
  let a real user achieve a goal end to end.
- Keep the map current as you learn. Move stories between slices instead of
  adding new documents.
-->

| Field | Value |
|---|---|
| Product / feature | [Name] |
| Map owner | [@product-owner] |
| Participants | [@designer], [@dev-lead], [@qa], [@stakeholder] |
| Mapping session date | YYYY-MM-DD |
| Version | [0.1] |
| Last updated | YYYY-MM-DD |
| Board link | [Link to digital board or photo] |

## 1. Product goal and scope

<!-- Guidance: One sentence on the outcome the product should create, and the boundary of this map. -->

**Goal.** [Who] will be able to [achieve what] so that [outcome].

*Example:* Independent fitness studios will be able to sell class passes
and take bookings online so that front-desk phone bookings fall by half.

**Scope of this map.** [The journey from first visit to repeat booking;
excludes payroll and instructor scheduling.]

## 2. Personas

<!-- Guidance: Two to four personas whose journeys appear on the map. Use names and specific goals, not demographics. -->

| Persona | Role | Goals | Frustrations today |
|---|---|---|---|
| *Example:* Maya, studio member | Customer | Book a class in under a minute from her phone | Has to call during opening hours |
| *Example:* Tom, studio owner | Administrator | Fill classes, get paid upfront | Spends 2 hours a day on the phone |
| *Example:* Lin, instructor | Staff | Know who is coming before class | Paper lists are out of date |
| [Name] | [Role] | [Goals] | [Frustrations] |

## 3. Backbone: user activities and tasks

<!-- Guidance: Activities are big things users do (verbs, high level). Tasks are the steps inside each activity. Order both left to right in narrative sequence. -->

| Order | Activity | User tasks (left to right) | Main persona |
|---|---|---|---|
| A1 | *Example:* Discover classes | Browse timetable; filter by type; view class details | Maya |
| A2 | *Example:* Buy a pass | Choose pass; create account; pay | Maya |
| A3 | *Example:* Book a class | Pick a slot; confirm booking; add to calendar | Maya |
| A4 | *Example:* Attend | Receive reminder; check in; cancel if needed | Maya, Lin |
| A5 | *Example:* Manage studio | Set up timetable; see bookings; view revenue | Tom |
| [An] | [Activity] | [Tasks] | [Persona] |

## 4. Walking skeleton

<!-- Guidance: The thinnest set of stories that lets one user go through the whole backbone, end to end, even crudely. Build this first. -->

The walking skeleton for this map is one story per activity:

| Activity | Skeleton story |
|---|---|
| A1 Discover classes | *Example:* See this week's timetable as a list |
| A2 Buy a pass | *Example:* Pay for a 10-class pass by card |
| A3 Book a class | *Example:* Book a slot with a pass credit |
| A4 Attend | *Example:* Instructor sees the booking list on a phone |
| A5 Manage studio | *Example:* Owner enters classes in a simple form |

## 5. Story map with release slices

<!-- Guidance: Each column is a task from the backbone; each row band is a release slice. Put the most essential story for each task at the top. -->

| Slice | Browse timetable | Filter | Choose and pay for pass | Book slot | Reminder and check-in | Owner dashboard |
|---|---|---|---|---|---|---|
| **Release 1: walking skeleton** | List of this week's classes | none | Card payment for 10-class pass | Book with pass credit | Instructor booking list | Enter classes in form |
| **Release 2: members self-serve** | Calendar view, 4 weeks ahead | By class type | Account with saved card | Waitlist when full | Email reminder 2 h before | Bookings per class |
| **Release 3: grow revenue** | Instructor profiles | By instructor, time | Memberships, promo codes | Recurring booking | QR check-in, late-cancel fee | Revenue and fill-rate report |
| [Release n] | [Story] | [Story] | [Story] | [Story] | [Story] | [Story] |

The same map is shown as a diagram, with activities on top and stories
grouped by release below.

```mermaid
flowchart TB
  subgraph Backbone
    direction LR
    A1[Discover classes] --> A2[Buy a pass] --> A3[Book a class] --> A4[Attend] --> A5[Manage studio]
  end
  subgraph R1["Release 1: walking skeleton"]
    direction LR
    S11[Weekly class list] ~~~ S12[Card payment] ~~~ S13[Book with credit] ~~~ S14[Instructor list] ~~~ S15[Class entry form]
  end
  subgraph R2["Release 2: members self-serve"]
    direction LR
    S21[Calendar view] ~~~ S22[Saved card] ~~~ S23[Waitlist] ~~~ S24[Email reminder] ~~~ S25[Bookings per class]
  end
  Backbone --> R1 --> R2
```

## 6. Release goals and success metrics

<!-- Guidance: Each slice has an outcome goal and a metric that tells you whether to continue, adjust or stop. -->

| Release | Goal | Success metric | Target | Measured by | Date |
|---|---|---|---|---|---|
| R1 | *Example:* Prove members will book online | Share of bookings made online at pilot studio | 30% within 4 weeks | Booking data | YYYY-MM-DD |
| R2 | *Example:* Cut front-desk phone load | Phone bookings per day | Down 50% from baseline | Studio log | YYYY-MM-DD |
| R3 | *Example:* Increase revenue per class | Average fill rate | 75% | Owner dashboard | YYYY-MM-DD |
| [Rn] | [Goal] | [Metric] | [Target] | [Source] | YYYY-MM-DD |

## 7. Story template and acceptance criteria

<!-- Guidance: Write stories as a promise of a conversation. Acceptance criteria use Given/When/Then so they turn directly into tests. -->

**Story format.** As a [persona], I want [capability] so that [benefit].

| Field | Value |
|---|---|
| Story ID | [KEY-nnn] |
| Activity / task | [A3 / Book slot] |
| Release slice | [R2] |
| Estimate | [Points] |
| Dependencies | [KEY-nnn] |

*Example:* **KEY-214** As Maya, a studio member, I want to join a waitlist
when a class is full so that I get a place if someone cancels.

Acceptance criteria:

- **Given** a class is full and I have a pass credit, **when** I select
  "Join waitlist", **then** I see my position in the waitlist.
- **Given** I am first on the waitlist, **when** a booked member cancels,
  **then** I am booked automatically, one credit is used and I receive an
  email.
- **Given** the class starts in less than 1 hour, **when** a place frees
  up, **then** waitlisted members are not auto-booked and the place is
  shown as available.

## 8. Mapping session agenda

<!-- Guidance: A 3 to 4 hour session for a new map. Timebox each step and keep the group to 5 to 8 people. -->

| Time | Step | Output |
|---|---|---|
| 0:00 | Introduce goal, personas and scope | Shared understanding |
| 0:20 | Silent writing: each person writes user tasks on cards | Raw tasks |
| 0:40 | Arrange tasks left to right; group into activities | Backbone |
| 1:10 | Walk the narrative aloud; fill gaps | Complete backbone |
| 1:30 | Break | Rest |
| 1:40 | Add stories, alternatives and details under each task | Story body |
| 2:30 | Draw slice lines: walking skeleton, then releases by outcome | Release slices |
| 3:10 | Define goals and metrics for each slice; list open questions | Sections 6 and 9 |
| 3:30 | Close: owners for follow-up actions | Action list |

## 9. Open questions and assumptions

| ID | Question or assumption | Owner | Due | Status |
|---|---|---|---|---|
| Q-01 | *Example:* Do studios accept card payment only, or cash at desk too? | [@po] | YYYY-MM-DD | Open |
| A-01 | *Example:* Members book mainly on mobile | [@ux] | YYYY-MM-DD | To validate in R1 |
| [ID] | [Question] | [@name] | YYYY-MM-DD | [Status] |

## Standard and licence note

Based on the story mapping technique described by Jeff Patton in *User
Story Mapping: Discover the Whole Story, Build the Right Product*
(O'Reilly, 2014), and on the common Given/When/Then convention for
acceptance criteria. This template is original text written for this
collection and reproduces no text from the book. Template licence: MIT.