Use this when you need to organize user stories into a visual story map showing the user's journey across activities (the backbone) with detailed tasks underneath, sliced into releases or iterations. Story mapping (Jeff Patton's technique) helps teams see the big picture of user workflow, identify gaps in coverage, and make informed decisions about what to build first.
Process
Step 1: Gather inputs
Ask the user:
- Product or feature area — What are you mapping? (Entire product, a specific workflow, a feature area.)
- User activity — What is the user trying to accomplish end-to-end? Describe the high-level workflow in plain language (e.g., "A new employee completes onboarding from offer acceptance to productive first week").
- Existing stories or backlog — Do you have stories already written? Provide them if so — the map will organize existing work rather than inventing new stories.
- Release or iteration context — Are you slicing for a specific release? How many iterations or releases are you planning?
- Known gaps — Any parts of the workflow you know are missing stories or poorly understood?
Step 2: Identify which personas walk this journey
Before mapping, prompt the user:
Persona check: Which user persona(s) walk through this activity? If you have defined personas (e.g., from
/persona-createor/persona-draft), name them. If not, describe the key user type briefly.A story map follows one persona's journey. If multiple personas have different journeys through the same activity, note where their paths diverge — these divergence points often reveal missing stories.
Step 3: Build the backbone (activities and steps)
Identify the high-level activities and the steps within each:
## Story Map — (Product/Feature/Workflow Name)
**Date:** (Date)
**Persona:** (Primary persona walking this journey)
**End-to-end activity:** (What the user is trying to accomplish)
---
### Backbone (left to right = sequence of user activities)
| Activity 1: (Name) | Activity 2: (Name) | Activity 3: (Name) | Activity 4: (Name) |
|---|---|---|---|
| (User step 1.1) | (User step 2.1) | (User step 3.1) | (User step 4.1) |
| (User step 1.2) | (User step 2.2) | (User step 3.2) | (User step 4.2) |
| (User step 1.3) | (User step 2.3) | | (User step 4.3) |
Activities are the big horizontal chunks of the user's journey (what they're trying to do).
Steps are the specific actions within each activity (how they do it).
Step 4: Map stories under each step
Place user stories under each step, organized by detail level:
### Story Detail (top to bottom = priority within each column)
#### Activity 1: (Name)
**Step 1.1: (Step name)**
- (Story — essential functionality for this step)
- (Story — additional detail or edge case)
- (Story — nice-to-have enhancement)
**Step 1.2: (Step name)**
- (Story — essential)
- (Story — additional)
#### Activity 2: (Name)
**Step 2.1: (Step name)**
- (Story — essential)
- (Story — additional)
- (Story — edge case)
(Continue for all activities and steps)
Step 5: Slice into releases
Draw horizontal lines across the map to define release boundaries:
### Release Slicing
#### Release 1: (Name — e.g., "Walking Skeleton" or "MVP")
**Goal:** (What this release accomplishes — the thinnest end-to-end slice that's usable)
| Activity 1 | Activity 2 | Activity 3 | Activity 4 |
|---|---|---|---|
| (Story) | (Story) | (Story) | (Story) |
| (Story) | | (Story) | |
**Story count:** (N)
**Key principle:** This slice must cover every activity at a basic level — the user can complete the entire journey, even if some steps are manual or minimal.
#### Release 2: (Name — e.g., "Core Polish" or "Beta")
**Goal:** (What this release adds)
| Activity 1 | Activity 2 | Activity 3 | Activity 4 |
|---|---|---|---|
| (Story) | (Story) | (Story) | (Story) |
| | (Story) | | (Story) |
**Story count:** (N)
#### Release 3+: (Name)
**Goal:** (What this release adds)
(Continue as needed)
### Gap Analysis
- **Missing coverage:** (Activities or steps with no stories — these are gaps in the user's journey)
- **Thin columns:** (Steps with only 1 story — may need more detail before implementation)
- **Orphan stories:** (Stories that don't fit under any step — these may belong to a different persona's journey or indicate a missing activity)
- **Persona divergence points:** (Where different personas would need different stories for the same step)
Step 6: Review and validate
Ask the user:
- Does the backbone capture the complete user journey? Any activities missing?
- Is Release 1 truly a complete (if minimal) end-to-end experience?
- Are there stories in later releases that actually need to be in Release 1 for viability?
- Do the gaps identified match your known unknowns?
- Would walking through this map with the team surface disagreements about scope or sequence?
Adjust as needed. The map is a living artifact — it should evolve as the team learns.
Related skills
/story-write— write detailed stories with acceptance criteria for items identified in the map./story-split— split stories that are too large for a single iteration./persona-draft— draft the persona whose journey the map follows./backlog-refine— refine the backlog after story mapping populates it./ipm-plan— plan iterations using the release slices from the map./moscow— if MoSCoW categorization is preferred over horizontal release slicing.
Output location
Present the story map (backbone, story detail, release slices, and gap analysis) as formatted text in the conversation. The user transfers the map to Miro, FigJam, a physical wall, or their project documentation.
Example Output
Input
- Product or feature area: Expense reporting workflow within Meridian Financial's internal ERP system
- User activity: A field sales employee submits a business trip expense report — from logging individual receipts through manager approval and reimbursement to their paycheck
- Existing stories: Partial backlog exists: receipt upload, expense line entry, currency conversion, policy violation flag, manager email notification, approval/rejection action, finance export to payroll, reimbursement confirmation email
- Release context: Two releases planned — R1 is a working MVP replacing the current Excel-email process, R2 adds automation and edge case handling
- Known gaps: Mileage tracking and per diem calculations are known unknowns; no stories exist for delegation (approver out of office)
Output
Story Map — Expense Reporting Workflow
Date: 2025-06-14 Persona: Taylor, Field Sales Representative (submitter); Marcus, Regional Sales Manager (approver) End-to-end activity: Field employee submits a business trip expense report, receives manager approval, and is reimbursed via payroll
Backbone
| Activity 1: Capture Expenses | Activity 2: Build & Submit Report | Activity 3: Review & Approve | Activity 4: Process Reimbursement |
|---|---|---|---|
| Upload receipt | Create report and add lines | Manager receives notification | Finance exports approved report |
| Enter expense details | Apply expense categories | Review line items and receipts | Payroll processes reimbursement |
| Log mileage or per diem | Check policy compliance | Approve, reject, or request edits | Employee receives confirmation |
| Handle foreign currency | Submit for approval | Delegate approval if unavailable |
Story Detail
Activity 1: Capture Expenses
Step: Upload receipt
- As Taylor, I can photograph and upload a receipt from my phone so I don't lose paper copies on the road
- As Taylor, I can upload PDF receipts from email so I can capture e-receipts without printing
- As Taylor, I can bulk-upload multiple receipts at once so I can process a full trip in one session
Step: Enter expense details
- As Taylor, I can enter merchant name, date, amount, and expense type for each receipt so the report has complete line items
- As Taylor, I can edit previously entered details before submission so I can correct mistakes
Step: Log mileage or per diem
- As Taylor, I can enter miles driven with a start/end description so mileage is reimbursed at the IRS rate (gap — no story exists)
- As Taylor, I can claim a daily per diem for eligible trip days so I don't need receipts for meals under the threshold (gap — no story exists)
Step: Handle foreign currency
- As Taylor, I can enter an amount in a foreign currency and see the USD equivalent auto-converted so I don't manually look up exchange rates
Activity 2: Build & Submit Report
Step: Create report and add lines
- As Taylor, I can create a named expense report tied to a trip date range so related expenses are grouped
- As Taylor, I can add multiple expense lines from my uploaded receipts to a single report
Step: Apply expense categories
- As Taylor, I can select from a standard category list (airfare, hotel, meals, ground transport) so expenses are coded consistently
Step: Check policy compliance
- As Taylor, I am shown a warning when a line item exceeds the per-category policy limit so I can add a justification before submitting
- As Taylor, I can attach a business justification note to a flagged expense so my manager has context for exceptions
Step: Submit for approval
- As Taylor, I can submit the completed report with one action so it enters the approval queue immediately
Activity 3: Review & Approve
Step: Manager receives notification
- As Marcus, I receive an email notification when a direct report submits an expense report so I can act promptly
- As Marcus, I can see all pending approvals in a dashboard so I have a single view of my queue
Step: Review line items and receipts
- As Marcus, I can view each expense line with its attached receipt image so I can verify the claim without requesting originals
- As Marcus, I can see which lines are policy-flagged and read the submitter's justification so I can make an informed decision
Step: Approve, reject, or request edits
- As Marcus, I can approve an entire report with a single action so routine reports don't require line-by-line interaction
- As Marcus, I can reject a report with a written reason so Taylor understands what to fix
- As Marcus, I can send a report back to Taylor with a comment requesting a specific correction so I don't have to reject valid claims outright
Step: Delegate approval if unavailable
- As Marcus, I can designate a delegate approver for a date range so reports aren't blocked when I'm traveling (gap — no story exists)
- As an HR admin, I can assign a temporary delegate when a manager is on extended leave so the queue doesn't stall (gap — no story exists)
Activity 4: Process Reimbursement
Step: Finance exports approved report
- As a Finance team member, I can export all approved reports in a payroll-ready format so reimbursements are included in the next pay cycle
Step: Payroll processes reimbursement
- As a Finance team member, I can mark an approved report as "submitted to payroll" so its status is updated and it's removed from the active queue
Step: Employee receives confirmation
- As Taylor, I receive an email confirmation when my report has been sent to payroll so I know when to expect reimbursement and don't need to follow up manually
Release Slicing
Release 1: Working MVP — "Replace the Spreadsheet"
Goal: Any field employee can complete a full expense submission end-to-end digitally. Mileage and per diem are out of scope; those remain on the current Excel form temporarily.
| Activity 1: Capture | Activity 2: Build & Submit | Activity 3: Review & Approve | Activity 4: Process |
|---|---|---|---|
| Upload receipt (mobile + PDF) | Create report, add lines | Manager email notification | Finance export to payroll |
| Enter expense details | Apply expense categories | View lines + receipts | Mark submitted to payroll |
| Foreign currency conversion | Policy flag + justification | Approve or reject with comment | Employee confirmation email |
| Submit for approval | Approval dashboard |
Story count: 14 Key principle: Taylor can complete the entire journey without touching Excel. Finance can export without manual data entry. Every activity has at least a minimal story covered.
Release 2: Automation & Edge Cases — "Production Ready"
Goal: Close the known gaps (mileage, per diem, delegation), add bulk receipt upload, and enable send-back without full rejection.
| Activity 1: Capture | Activity 2: Build & Submit | Activity 3: Review & Approve | Activity 4: Process |
|---|---|---|---|
| Mileage entry + auto-rate calc | Bulk-upload receipts | Send back with comment (not reject) | — |
| Per diem daily claim | Edit details pre-submission | Delegate approver (self-service) | — |
| — | — | Admin-assigned delegation | — |
Story count: 7
Gap Analysis
- Missing coverage: Mileage tracking and per diem — two full steps in Activity 1 have zero existing stories; these need story-writing sessions before R2 planning
- Thin columns: Activity 4 (Process Reimbursement) has only 3 stories total; the payroll integration failure/retry path is unaddressed — likely needs a spike
- Orphan stories: None identified; all backlog items mapped cleanly to steps
- Persona divergence points: Marcus's journey branches at Activity 3 — the delegation stories belong entirely to the approver persona and have no submitter equivalent; treat as a separate column slice in Miro to avoid confusion during sprint planning
Next Steps
- Run a story-writing session on mileage and per diem before R2 kickoff (
/story-write) - Spike on payroll system integration failure handling in R1 sprint 3
- Validate R1 scope with Marcus — confirm send-back-without-reject is acceptable to defer
- Transfer backbone to FigJam wall with physical swim lanes for team walkthrough at next IPM