A structured framework for capturing product requirements from the user's perspective. User stories help teams understand who needs a feature, what they want to accomplish, and why it matters.
When to Use This Skill
- Writing backlog items
- Defining feature requirements
- Prioritizing development work
- Communicating with development teams
- Breaking down epics into actionable work
- Ensuring user focus in product decisions
User Story Format
THE STANDARD TEMPLATE
"As a [type of user], I want [some goal], so that [some reason/benefit]."
Components: ┌─────────────────────────────────────────────────────┐ │ WHO: The user persona or role │ │ WHAT: The desired functionality or goal │ │ WHY: The business value or user benefit │ └─────────────────────────────────────────────────────┘
This format shifts focus from WRITING about requirements to TALKING about them, with users at the center.
## Core Components
### WHO - User Persona
Specificity Spectrum:
Generic (avoid): ├── "As a user..." └── "As a customer..."
Better: ├── "As a first-time visitor..." ├── "As a returning customer..." ├── "As an admin user..." └── "As a mobile user..."
Best (with job context): ├── "As a marketing manager who needs weekly reports..." ├── "As a parent shopping for school supplies..." ├── "As a developer debugging production issues..." └── "As a sales rep preparing for a client meeting..."
### WHAT - Desired Functionality
Focus on GOALS, not IMPLEMENTATION:
❌ "I want a blue button in the header" (prescriptive, limits solutions)
✓ "I want to quickly access my saved items" (goal-focused, enables creativity)
❌ "I want a REST API endpoint" (technical implementation)
✓ "I want to integrate my data with external tools" (user goal, flexible implementation)
### WHY - Business Value
The "So That" Connection:
This part explains: ├── What pain it solves ├── What value it creates ├── Why this matters to the user └── How it connects to business goals
Without "so that": "As a user, I want to filter search results" → Why? What's the actual need?
With "so that": "As a user, I want to filter search results so that I can find relevant items faster when browsing large catalogs" → Clear value, enables better solutions
## INVEST Criteria
QUALITY CHECKLIST FOR USER STORIES
I - Independent │ Can be developed and delivered separately │ No tight coupling to other stories │ N - Negotiable │ Details open to discussion │ Not a rigid contract │ V - Valuable │ Delivers real value to user or business │ Not just technical tasks │ E - Estimable │ Team can estimate effort │ Clear enough to size │ S - Small │ Fits within single sprint │ If too big, split it │ T - Testable │ Has clear acceptance criteria │ Can verify when complete
## Acceptance Criteria
### Definition
ACCEPTANCE CRITERIA (AC)
Purpose: Define what makes the story "done" Format: Specific, testable conditions
Example Story: "As a user, I want to reset my password via email so that I can regain access if I forget it"
Acceptance Criteria: □ User can request reset from login page □ Email sent within 60 seconds of request □ Reset link expires after 24 hours □ Link works only once □ Password must meet security requirements □ User receives confirmation after successful reset
### Writing Good AC
| Characteristic | Example |
| --------------- | -------------------------------------------- |
| Specific | "Within 60 seconds" not "quickly" |
| Testable | "Email contains reset link" - can verify |
| Outcome-focused | "User can access account" not "system sends" |
| Complete | Covers happy path AND edge cases |
## Prioritization Framework
### RICE Scoring
RICE = (Reach × Impact × Confidence) / Effort
Reach: How many users affected per time period? (100 users/month, 1000 users/quarter)
Impact: How much will it move the needle? 3 = Massive, 2 = High, 1 = Medium, 0.5 = Low, 0.25 = Minimal
Confidence: How sure are we about estimates? 100% = High, 80% = Medium, 50% = Low
Effort: Person-months of work (0.5, 1, 2, 3...)
Higher RICE score = Higher priority
### MoSCoW Method
CATEGORIZATION FOR RELEASE PLANNING
MUST Have (Non-negotiable) ├── Critical for release ├── Legal/compliance requirements └── Core value proposition
SHOULD Have (Important) ├── High value but not critical ├── Workarounds exist └── Strong user demand
COULD Have (Nice to have) ├── Desired but not necessary ├── Easy wins if time permits └── Lower user impact
WON'T Have (Not this time) ├── Explicitly out of scope ├── Future consideration └── Documented for later
## Story Splitting Techniques
### When to Split
SPLIT IF: ├── Can't complete in one sprint ├── Story points > 13 (or team max) ├── Multiple distinct user values ├── Contains "and" connecting features └── Too many acceptance criteria
### Splitting Methods
-
BY WORKFLOW STEPS Original: "User can complete purchase" Split: ├── User can add items to cart ├── User can enter shipping info ├── User can enter payment info └── User can confirm and place order
-
BY USER TYPE Original: "User can view dashboard" Split: ├── Admin can view full dashboard ├── Manager can view team metrics └── User can view personal stats
-
BY OPERATIONS (CRUD) Original: "User can manage contacts" Split: ├── User can create contact ├── User can view contact details ├── User can edit contact └── User can delete contact
-
BY DATA VARIATIONS Original: "User can import data" Split: ├── User can import CSV files ├── User can import Excel files └── User can import from API
-
BY ACCEPTANCE CRITERIA Original: "User can search products" Split: ├── User can basic keyword search ├── User can filter by category ├── User can sort results └── User can save search
## Definition of Done vs. Acceptance Criteria
DEFINITION OF DONE (DoD) ACCEPTANCE CRITERIA (AC) ──────────────────────── ──────────────────────── Universal checklist Story-specific conditions Same for all stories Unique per story Quality standard Functional requirements
DoD Examples: AC Examples: □ Code reviewed □ User can X □ Tests written □ System does Y □ Documentation updated □ Data validates as Z □ No critical bugs □ Performance meets N
## Story Template
```markdown
## User Story
**ID:** [PROJ-123] **Title:** [Brief descriptive title]
### Story
As a [specific user type], I want [goal/desire], so that [benefit/value].
### Acceptance Criteria
- [ ] [Specific, testable condition 1]
- [ ] [Specific, testable condition 2]
- [ ] [Specific, testable condition 3]
### Notes
- [Additional context]
- [Technical considerations]
- [Dependencies]
### Attachments
- [Link to designs]
- [Link to research]
### Estimation
- **Story Points:** [X]
- **Priority:** [High/Medium/Low]
- **Sprint:** [Sprint N]
Real-World Examples
E-commerce
Story: Password-less Login
As a returning customer,
I want to login using a magic link sent to my email,
so that I can access my account without remembering passwords.
Acceptance Criteria:
□ User enters email on login page
□ "Send magic link" option available
□ Email received within 30 seconds
□ Link valid for 15 minutes
□ One-click login from email
□ User lands on their dashboard after login
□ Link cannot be reused after login
SaaS Product
Story: Team Invitation
As an account admin,
I want to invite team members via email,
so that I can onboard my team without manual account creation.
Acceptance Criteria:
□ Admin can enter multiple email addresses
□ Invitation email clearly explains next steps
□ Invited user can set their own password
□ Admin can see pending invitations
□ Admin can revoke pending invitations
□ Duplicate email addresses are prevented
□ Admin can set role during invitation
Common Mistakes
ANTI-PATTERNS TO AVOID
❌ Implementation as story
"Create database table for users"
→ Not user value, technical task
❌ Missing "so that"
"As a user, I want to search"
→ Why? What problem does this solve?
❌ Too vague
"As a user, I want a better experience"
→ What specifically? Not actionable
❌ Too large
"As a user, I want full account management"
→ Multiple features, needs splitting
❌ Solution prescribed
"As a user, I want a dropdown menu"
→ Describes UI, not user goal
Integration with Other Methods
| Method | Combined Use |
|---|---|
| Theme-Epic-Story | Stories fit within epic hierarchy |
| Jobs to Be Done | Stories address user jobs |
| Five Whys | Find root cause behind story need |
| Hypothesis Tree | Stories as hypotheses to test |
| Kanban | Stories flow through board stages |
Quick Reference
STORY WRITING CHECKLIST
Format:
□ Follows "As a... I want... so that..." format
□ User type is specific and meaningful
□ Goal is user-focused, not technical
□ Benefit clearly stated
Quality (INVEST):
□ Independent - can be built alone
□ Negotiable - details discussable
□ Valuable - delivers real value
□ Estimable - team can size it
□ Small - fits in single sprint
□ Testable - has clear AC
Acceptance Criteria:
□ Specific and measurable
□ Testable (can verify pass/fail)
□ Covers main scenarios
□ Includes edge cases
□ Outcome-focused