Write Story Map

Step 2: Build the Backbone

The backbone is the sequence of high-level activities the user performs to achieve their goal. Activities read left-to-right as a narrative.

Rules for Activities

• Activities are verb phrases — "Review Applications", "Schedule Interviews", "Make Decision" — not nouns
• Activities are chronological or logical — they follow the order the user naturally performs them
• 3-7 activities is typical — fewer than 3 means you are too abstract; more than 7 means you are too granular
• Activities are NOT features — "Use the Dashboard" is a feature. "Monitor Progress" is an activity

Example Backbone

Create Posting → Source Candidates → Review Applications → Interview → Evaluate → Hire

Write each activity with a one-sentence description of what the user is doing and why.

Step 3: Walk the Happy Path

Under each activity, list the tasks that make up the minimal happy path — the simplest way to complete each activity successfully.

Rules for Tasks

• Tasks are concrete user actions — "Write job description", "Post to job board", "Read resume"
• Tasks sit under exactly one activity — if a task spans two activities, it is too big. Split it
• Order tasks top-to-bottom by necessity — most essential tasks at the top, nice-to-haves lower down
• Each task becomes a user story — it should be small enough for one engineer to complete in 1-5 days

Example

Create Posting          Source Candidates       Review Applications
├── Write description   ├── Post to job board   ├── View applicant list
├── Set requirements    ├── Share link           ├── Read resume
├── Get approval        ├── Receive referrals    ├── Score candidate

The happy path is the top row of tasks — the minimal set that gets the user from start to finish.

Step 4: Add Detail

Below the happy path, add tasks for:

1. Alternative paths — other ways to accomplish the activity ("Bulk import candidates" under Source Candidates)
2. Edge cases — what happens when things go wrong ("Handle duplicate applications" under Review Applications)
3. Error handling — recovery from failures ("Reopen closed posting" under Create Posting)
4. Supporting tasks — necessary but not user-facing ("Sync with ATS" under Source Candidates)

Place these below the happy-path tasks, ordered by priority (most important first). Each row down is less critical than the row above.

Step 5: Slice Releases

Draw horizontal lines across the map to define release boundaries. Each slice is a shippable increment.

Slice 1: Walking Skeleton

The thinnest possible end-to-end slice that demonstrates the full flow. It must:

• Touch every activity in the backbone (at least one task per activity)
• Be deployable and usable (not a prototype — real code, real data)
• Validate the architecture (proves the system can support the full flow)

The walking skeleton is NOT an MVP. It is smaller — it proves the flow works, not that it is valuable to users.

Slice 2: MVP

The minimum set of tasks that delivers enough value for real users to adopt. It must:

• Include the walking skeleton
• Add enough depth to each activity that users can complete their goal without workarounds
• Be the smallest thing you would put in front of a paying customer

Slice 3+: Enhancements

Additional tasks that improve the experience, add alternative paths, or handle edge cases. Group them into coherent releases — each release should make a specific aspect noticeably better.

Slice Rules

• Every slice must touch every activity — a release that only covers "Create Posting" is not a slice, it is a component. Users need end-to-end value
• Walking skeleton first, always — do not build one activity deeply before proving the full flow works
• Each slice is independently shippable — it must work on its own, not depend on a future slice

Step 6: Validate Coverage

Before finalising, verify the map:

Rules

• The backbone tells a story — read the activities left-to-right as a sentence. If it does not make narrative sense, the ordering or naming is wrong.
• Walking skeleton = thinnest possible slice that demonstrates the full flow — not "the most important feature". It must span all activities.
• Stories above the line are more important than stories below — vertical position is priority. The team reads the map top-to-bottom.
• No story exists without an activity above it — orphan stories indicate a missing backbone activity. Find the activity or discard the story.
• A story map is not a backlog — it is a 2D spatial arrangement. If you flatten it into a list, you lose the narrative structure and the release slicing.
• Do not map what you will not build — if an activity is out of scope, exclude it from the backbone. Note it in the scope boundary.
• Reference User Story Mapping by Jeff Patton for the definitive methodology.

Output Format

# Story Map: [Feature Area / Epic]

## User and Goal

| Field | Description |
|-------|-------------|
| **User** | [Specific role + context] |
| **Goal** | [End-to-end outcome] |
| **Journey** | [Start] → [End] |
| **Scope boundary** | [What is excluded] |

## Story Map

| | Activity 1 | Activity 2 | Activity 3 | Activity 4 | Activity 5 |
|---|---|---|---|---|---|
| **Backbone** | [Activity name] | [Activity name] | [Activity name] | [Activity name] | [Activity name] |
| **Walking Skeleton** | [Task] | [Task] | [Task] | [Task] | [Task] |
| **MVP** | [Task] | [Task] | [Task] | [Task] | [Task] |
| | [Task] | [Task] | | [Task] | |
| **Enhancement** | [Task] | [Task] | [Task] | [Task] | [Task] |
| | [Task] | | [Task] | | [Task] |
| **Future** | [Task] | [Task] | | [Task] | |

## Release Slices

### Slice 1: Walking Skeleton
- **Goal:** Prove the end-to-end flow works
- **Stories:** [list of tasks from the walking skeleton row]
- **Definition of done:** User can complete the full journey, even if manually or with minimal features

### Slice 2: MVP
- **Goal:** Deliver enough value for real adoption
- **Stories:** [list of tasks from the MVP row]
- **Definition of done:** User can complete their goal without workarounds

### Slice 3: [Enhancement theme]
- **Goal:** [What this release improves]
- **Stories:** [list of tasks]
- **Definition of done:** [Measurable improvement]

## Validation Checklist

- [ ] Backbone covers full user journey (start to finish)
- [ ] No orphan stories (every task has an activity)
- [ ] Walking skeleton touches every activity
- [ ] Each task is independently deliverable
- [ ] Edge cases and error paths are represented
- [ ] Each release slice is independently shippable

Write the output to a file: docs/story-map-[feature].md.

Related Skills

• /product-owner:write-user-story — write detailed user stories (with Gherkin acceptance criteria) for individual tasks from the map.
• /product-owner:groom-backlog — prioritise the mapped stories within the backlog.
• /coordinator:decompose-initiative — decompose a large initiative before mapping individual features.

Use the story map template (templates/story-map.md) for output structure.