User Story Generator: Generating user stories...
Produces prioritized user stories with Given/When/Then acceptance criteria, story point estimates, story mapping across epics, and MoSCoW prioritization for sprint planning.
Activation
When this skill activates, output:
User Story Generator: Generating user stories...
Then execute the protocol below.
Context Guard
| Context | Status |
|---|---|
| User says "user stories", "write stories", "backlog" | ACTIVE |
| User says "sprint planning" or "acceptance criteria" | ACTIVE |
| User wants to break work into estimable, assignable stories | ACTIVE |
| User wants a full product requirements document | DORMANT: use PRD Writer |
| User wants a detailed spec for one feature | DORMANT: use Feature Spec |
Common Mistakes
| Mistake | Why It's Wrong |
|---|---|
| "As a user, I want the system to..." | Stories describe user needs, not system behavior. The "I want to" should be a user action. |
| "Write a story for every edge case" | Edge cases go in acceptance criteria, not separate stories. One story per user intent. |
| "Stories without acceptance criteria" | "Done" becomes subjective. Every story needs testable criteria before sprint planning. |
| "Estimate in hours" | Hours vary by person. Story points measure relative complexity, not calendar time. |
| "50-point stories in the sprint" | If it's bigger than 8 points, split it. Large stories hide unknowns and block the team. |
Protocol
Step 1: Gather Context
If the user hasn't provided details, ask:
- Feature/epic: what area are you writing stories for?
- Personas: who are the users? (roles, permissions, experience levels)
- Existing context: is there a PRD, feature spec, or design to reference?
- Sprint goal: what are you trying to ship this sprint?
- Team capacity: how many story points can the team handle? (helps scope)
Step 2: Identify Epics & Themes
Group stories under epics (large bodies of work):
markdown## Story Map ### Epic 1: [Epic Name] **Theme:** [What area of the product this covers] **Goal:** [What completing this epic achieves] Stories: - [ ] US-001: [Story title] - [ ] US-002: [Story title] - [ ] US-003: [Story title] ### Epic 2: [Epic Name] **Theme:** [Theme] **Goal:** [Goal] Stories: - [ ] US-004: [Story title] - [ ] US-005: [Story title]
Story mapping layout:
User Journey → ┌─────────────────────────────────────────────┐ │ Step 1 │ Step 2 │ Step 3 │ Epics ─────┼─────────────┼─────────────┼─────────────────┤ │ US-001 (M) │ US-003 (M) │ US-006 (M) │ ← Must │ US-002 (S) │ US-004 (S) │ US-007 (C) │ ← Should/Could │ │ US-005 (C) │ │ └─────────────┴─────────────┴─────────────────┘
The top row of each column is the minimum to deliver a working user journey. Everything below is enhancement.
Step 3: Write User Stories
Story template:
markdown### US-[ID]: [Short descriptive title] **As a** [persona/role], **I want to** [action/capability], **So that** [benefit/outcome]. **Priority:** [Must / Should / Could / Won't] **Story points:** [1 / 2 / 3 / 5 / 8] **Epic:** [Parent epic] **Dependencies:** [US-XXX or None] #### Acceptance Criteria **AC-1: [Happy path]** Given [precondition] When [user action] Then [expected result] **AC-2: [Validation/error]** Given [precondition] When [invalid action or error condition] Then [error handling behavior] **AC-3: [Edge case or permission]** Given [special condition] When [action] Then [expected behavior] #### Notes - [Design reference, API dependency, or technical consideration] - [Out of scope for this story: X, Y]
Story writing rules:
- One user intent per story (splittable, not compound)
- The "so that" must describe a user benefit, not a system behavior
- 2-5 acceptance criteria per story (if you need more, split the story)
- Include at least one error/validation criterion per story
- Stories should be completable within one sprint
Step 4: Estimate with Story Points
Fibonacci scale reference:
| Points | Relative Size | Team Example | Typical Duration |
|---|---|---|---|
| 1 | Trivial | Copy change, config update | Hours |
| 2 | Small | Simple UI component, basic CRUD | 0.5-1 day |
| 3 | Medium | Feature with some logic, API integration | 1-2 days |
| 5 | Large | Complex feature, multiple components | 2-4 days |
| 8 | Very large | Multi-system integration, new architecture | 3-5 days |
| 13 | Epic-level | Should be split into smaller stories | Split it |
Estimation heuristic:
- Pick a reference story the team agrees is a "3" (your baseline)
- Compare each new story: "Is this bigger or smaller than a 3?"
- Account for: complexity, uncertainty, testing effort, and coordination needed
- If you can't estimate confidently → add a spike story (time-boxed research)
Spike story template:
markdown### US-[ID]: [Spike] Investigate [unknown] **As a** developer, **I want to** research [technical question or unknown], **So that** we can estimate and plan [dependent stories]. **Time box:** [X hours/days] **Output:** Decision document with recommendation #### Acceptance Criteria - [ ] [Specific question 1] is answered - [ ] [Specific question 2] is answered - [ ] Recommendation documented for team review
Step 5: Prioritize (MoSCoW + Value/Effort)
MoSCoW assignment:
| Priority | Stories | Rationale |
|---|---|---|
| Must | US-001, US-003, US-006 | Product doesn't function without these |
| Should | US-002, US-004 | Important for good experience, not blocking |
| Could | US-005, US-007 | Nice to have, include if sprint has capacity |
| Won't | US-008 | Deferred to future sprint |
Value/Effort matrix:
High Value │ Quick Wins │ Strategic (Do first) │ (Plan carefully) ────────────────┼──────────────── Fill-ins │ Avoid (for now) (If time) │ (High cost, low reward) │ Low Value Low Effort ──────── High Effort
Place each story on the matrix. Sprint should be loaded with Quick Wins and Strategic items.
Step 6: Organize Sprint Backlog
Sprint planning output:
markdown## Sprint [X] Backlog: [Sprint Goal] **Capacity:** [X] story points **Duration:** [2 weeks] **Sprint goal:** [One sentence: what we're shipping] ### Committed Stories | ID | Story | Points | Priority | Assignee | Dependencies | |----|-------|--------|----------|----------|-------------| | US-001 | [Title] | 3 | Must | [Name] | None | | US-003 | [Title] | 5 | Must | [Name] | US-001 | | US-002 | [Title] | 2 | Should | [Name] | None | | US-004 | [Title] | 3 | Should | [Name] | US-003 | | **Total** | | **13** | | | | ### Stretch Goals (if capacity) | US-005 | [Title] | 2 | Could | none | None | ### Not This Sprint | US-008 | [Title] | 8 | Won't | none | Needs design |
Sprint planning rules:
- Total committed points should not exceed team velocity
- Must stories go in first, then Should, then Could
- Respect dependency order (don't commit US-003 without US-001)
- Leave 10-20% buffer for bugs, reviews, and unexpected work
Output Format
markdown# User Stories: [Feature/Epic Name] ## Story Map [Epic/theme overview from Step 2] ## Stories ### US-001: [Title] [Full story from Step 3] ### US-002: [Title] [Full story from Step 3] [... all stories ...] ## Prioritization [MoSCoW table from Step 5] [Value/Effort matrix placement] ## Sprint Backlog [Sprint planning table from Step 6] ## Definition of Done - [ ] Code complete and reviewed - [ ] Unit tests passing - [ ] Acceptance criteria verified - [ ] No regressions in existing tests - [ ] Deployed to staging environment
Completion
User Story Generator: Complete! Epics: [Count] Total stories: [Count] Must-have: [Count] ([X] points) Should-have: [Count] ([X] points) Could-have: [Count] ([X] points) Total story points: [X] Sprint capacity needed: [X sprints] Next steps: 1. Review stories with the team (estimation poker) 2. Validate acceptance criteria with QA 3. Resolve any dependency blockers 4. Commit to Sprint [X] backlog 5. Create tasks/subtasks in project management tool
Level History
- Lv.1: Base: Epic/theme identification, story map layout, story template (As a/I want to/So that), Given/When/Then acceptance criteria, Fibonacci story points with estimation heuristic, spike story template, MoSCoW prioritization, value/effort matrix, sprint backlog organization with capacity planning, definition of done checklist. (Origin: MemStack Pro v3.2, Mar 2026)
