product-management
User Story Mapping
Create user story maps that break down complex features into shippable slices with clear user journeys, activities, tasks, and release planning.
user-storiesstory-mappingagileplanning
Works well with agents
Works well with skills
user-story-mapping/
SKILL.md
Markdown| 1 | |
| 2 | # User Story Mapping |
| 3 | |
| 4 | ## Before you start |
| 5 | |
| 6 | Gather the following from the user: |
| 7 | |
| 8 | 1. **What product/feature area** are we mapping? |
| 9 | 2. **Who are the users?** (List specific personas or segments, not "users") |
| 10 | 3. **What is the goal?** (Are we mapping for an MVP? A new feature? A redesign?) |
| 11 | 4. **What constraints exist?** (Timeline, team size, technical limitations) |
| 12 | |
| 13 | If the user gives you a vague scope ("map our product"), narrow it: "Which user journey should we focus on first?" |
| 14 | |
| 15 | ## Step 1: Identify the backbone (Activities) |
| 16 | |
| 17 | Activities are the high-level things users do. They read left-to-right as a narrative. |
| 18 | |
| 19 | Rules for activities: |
| 20 | - Use verb phrases: "Discover agents", "Configure workspace", "Monitor performance" |
| 21 | - Keep to 4-8 activities for a single feature area |
| 22 | - Order them chronologically as the user would experience them |
| 23 | - Each activity should be completable in one session |
| 24 | |
| 25 | ``` |
| 26 | [Discover agents] → [Evaluate agent] → [Install agent] → [Configure agent] → [Monitor usage] |
| 27 | ``` |
| 28 | |
| 29 | ## Step 2: Break activities into tasks |
| 30 | |
| 31 | Each activity contains 2-5 tasks. Tasks are the steps a user takes within an activity. |
| 32 | |
| 33 | Rules for tasks: |
| 34 | - Tasks are smaller verb phrases: "Search catalog", "Read reviews", "Compare options" |
| 35 | - Order them top-to-bottom by typical sequence |
| 36 | - Every task should map to an observable user action |
| 37 | |
| 38 | ``` |
| 39 | Activity: Discover agents |
| 40 | ├── Search catalog |
| 41 | ├── Browse categories |
| 42 | ├── View trending |
| 43 | └── Read recommendations |
| 44 | ``` |
| 45 | |
| 46 | ## Step 3: Generate stories under each task |
| 47 | |
| 48 | Stories are the specific, implementable items. Write them in standard format: |
| 49 | |
| 50 | > As a [persona], I want [action] so that [outcome]. |
| 51 | |
| 52 | Rules for stories: |
| 53 | - Each story must be independently deliverable |
| 54 | - Each story must be testable (you can write an acceptance criterion) |
| 55 | - Avoid technical stories at this stage — frame everything from the user's perspective |
| 56 | - It's okay to have 3-10 stories per task |
| 57 | |
| 58 | ``` |
| 59 | Activity: Discover agents |
| 60 | ├── Task: Search catalog |
| 61 | │ ├── As a developer, I want to search agents by keyword so that I can find relevant tools quickly |
| 62 | │ ├── As a developer, I want to filter search results by category so that I can narrow down options |
| 63 | │ └── As a developer, I want to see search results ranked by relevance so that the best matches appear first |
| 64 | ``` |
| 65 | |
| 66 | ## Step 4: Draw the release slices |
| 67 | |
| 68 | Slice the map horizontally. Each slice is a shippable release. |
| 69 | |
| 70 | **Slice 1 (Walking Skeleton / MVP)**: |
| 71 | - Pick the ONE story from each task that delivers the minimum end-to-end experience |
| 72 | - The user should be able to complete the entire journey, even if each step is bare-bones |
| 73 | - This slice should be shippable in 1-2 sprints |
| 74 | |
| 75 | **Slice 2 (v1.0)**: |
| 76 | - Add the stories that make the experience good, not just functional |
| 77 | - Better search, richer detail pages, smoother flows |
| 78 | |
| 79 | **Slice 3+ (Future)**: |
| 80 | - Everything else. Nice-to-haves, power user features, optimizations |
| 81 | |
| 82 | Rules for slicing: |
| 83 | - Every slice must be independently shippable and valuable |
| 84 | - The walking skeleton must include at least one story from each critical activity |
| 85 | - Don't put all the "easy" stories in slice 1 — put the most valuable ones |
| 86 | |
| 87 | ## Output format |
| 88 | |
| 89 | Present the final story map in this structure: |
| 90 | |
| 91 | ``` |
| 92 | # Story Map: [Feature/Product Name] |
| 93 | |
| 94 | ## Personas: [List them] |
| 95 | |
| 96 | --- |
| 97 | |
| 98 | ### Activity: [Name] |
| 99 | |
| 100 | #### Task: [Name] |
| 101 | - [MVP] Story description |
| 102 | - [v1.0] Story description |
| 103 | - [Future] Story description |
| 104 | |
| 105 | #### Task: [Name] |
| 106 | - [MVP] Story description |
| 107 | - [v1.0] Story description |
| 108 | |
| 109 | --- |
| 110 | |
| 111 | ### Activity: [Name] |
| 112 | ... |
| 113 | ``` |
| 114 | |
| 115 | ## Quality checklist |
| 116 | |
| 117 | Before delivering a story map, verify: |
| 118 | |
| 119 | - [ ] Activities read left-to-right as a coherent user narrative |
| 120 | - [ ] Every activity has 2-5 tasks |
| 121 | - [ ] Every story is independently deliverable and testable |
| 122 | - [ ] The MVP slice delivers a complete (if minimal) end-to-end journey |
| 123 | - [ ] No slice contains only backend/technical work with no user-facing value |
| 124 | - [ ] Stories are framed from the user's perspective, not technical tasks |
| 125 | - [ ] The map has been reviewed against the stated personas — does each persona have a clear path? |
| 126 | |
| 127 | ## Common mistakes to avoid |
| 128 | |
| 129 | - **Starting with stories instead of activities**. Always build the backbone first. Stories without a backbone are just a flat backlog. |
| 130 | - **MVP that's too thick**. The walking skeleton should be embarrassingly thin. If your MVP has more than 2 stories per task, you're not cutting enough. |
| 131 | - **Confusing tasks with stories**. "Search catalog" is a task. "As a developer, I want to search by keyword" is a story. Tasks are categories; stories are deliverables. |
| 132 | - **Leaving out the "return" journey**. Users don't just complete a flow once. Map what happens when they come back: re-evaluate, update, remove, monitor. |
| 133 |