User Story Creation
Break Product Backlog Items into implementable user stories using vertical slicing and SPIDR patterns.
When to Use
- PBI ready for story breakdown
- Feature needs vertical slicing
- Creating sprint-ready work items
- Story too large (effort >8)
Quick Reference
Workflow
- Read PBI artifact and acceptance criteria
- Load domain context (if BravoSUITE module detected)
- Identify vertical slices (end-to-end functionality)
- Apply SPIDR splitting if stories too large
- Apply INVEST criteria to each story
- Create user stories with GIVEN/WHEN/THEN (min 3 scenarios)
- Save to
team-artifacts/pbis/stories/ - Validate stories (MANDATORY) - Interview user to confirm slicing, acceptance criteria, and effort
- Suggest next:
/test-specor/design-spec
Output
- Path:
team-artifacts/pbis/stories/{YYMMDD}-us-{pbi-slug}.md - Format: Single file with all stories (use ## headers per story)
BravoSUITE Domain Context Loading
When slicing domain-related PBIs, automatically load business context.
Step 1: Detect Module
From PBI frontmatter:
- Check
modulefield - If missing, detect from keywords:
- bravoTALENTS: candidate, job, interview, recruitment, CV, applicant - bravoGROWTH: goal, kudos, performance, check-in, timesheet - bravoSURVEYS: survey, question, response, distribution - bravoINSIGHTS: dashboard, report, analytics
Step 2: Load Feature Context
Glob("docs/business-features/{module}/detailed-features/*.md")- Read module README (first 200 lines)
- Identify related feature from
related_featureslist - Extract existing business rules (BR-{MOD}-XXX)
- Note entity names from feature docs
Step 3: Apply Domain Vocabulary
| Module | Correct Term | Avoid |
|---|---|---|
| bravoTALENTS | Candidate | Applicant |
| bravoTALENTS | JobApplication | Application |
| bravoGROWTH | Goal | Objective |
| bravoGROWTH | Employee | User, Staff |
| bravoSURVEYS | Survey | Form, Questionnaire |
Step 4: Include in Story
## Domain Context
**Module:** {detected module}
**Feature:** {related feature}
**Entities:** {Entity1}, {Entity2}
**Business Rules:** BR-{MOD}-XXX (from feature docs)INVEST Criteria
| Criterion | Definition | Validation Question |
|---|---|---|
| Independent | No dependencies on other stories | Can this be developed in any order? |
| Negotiable | Details can change | Is the "how" open for discussion? |
| Valuable | Delivers user value | Does user get observable benefit? |
| Estimable | Can estimate effort | Can team size this? |
| Small | Completable in sprint | Effort ≤8? (prefer ≤5) |
| Testable | Clear acceptance criteria | Can we write pass/fail tests? |
SPIDR Splitting Checklist
When to apply: Story effort >8 MUST split. Effort >5 SHOULD split.
| Pattern | Question | Split Strategy |
|---|---|---|
| Spike | Unknown complexity? | Create research spike first, then stories |
| Paths | Multiple workflow branches? | One story per path/choice |
| Interfaces | Multiple UIs or APIs? | One story per interface |
| Data | Multiple data formats/types? | One story per data variation |
| Rules | Multiple business rules? | One story per rule variation |
Splitting Examples
Paths: "User can pay by card OR PayPal" → Story A: Card payment, Story B: PayPal payment
Data: "Import CSV, Excel, JSON" → Story A: CSV import, Story B: Excel import, Story C: JSON import
Rules: "Different approval flows by amount" → Story A: <$1000 auto-approve, Story B: >$1000 manager approval
Size Validation
Effort 1-5: ✅ Good size
Effort 6-8: ⚠️ Consider splitting (apply SPIDR)
Effort >8: ❌ MUST split (apply SPIDR, repeat until ≤8)Scenario Templates
Minimum 3 scenarios per story:
1. Happy Path (Positive)
Scenario: User successfully {completes action}
Given {user has required permissions/state}
And {required data exists}
When user {performs valid action}
Then {primary expected outcome}
And {secondary verification if needed}2. Edge Case (Boundary)
Scenario: System handles {boundary condition}
Given {edge state: empty list, max items, zero value}
When user {attempts action at boundary}
Then {appropriate handling: pagination, warning, default}3. Error Case (Negative)
Scenario: System prevents {invalid action}
Given {precondition}
When user {provides invalid input OR unauthorized action}
Then error message "{specific error message}"
And {system remains in valid state}
And {no partial changes saved}Additional Scenario Types
Security: Unauthorized access attempt Performance: Response time under load Concurrency: Simultaneous user actions Integration: External service unavailable
Story Artifact Template
---
id: US-{YYMMDD}-{NNN}
parent_pbi: "{PBI-ID}"
title: "{Brief story title}"
persona: "{User persona}"
priority: P1 | P2 | P3
effort: 1 | 2 | 3 | 5 | 8
status: draft | ready | in_progress | done
module: "{bravoTALENTS | bravoGROWTH | bravoSURVEYS | bravoINSIGHTS}"
---
# User Stories for {PBI Title}
## Story 1: {Title}
**As a** {user role}
**I want** {goal}
**So that** {benefit}
### Acceptance Criteria
#### Scenario 1: {Happy path title}Given {context} When {action} Then {outcome}
#### Scenario 2: {Edge case title}
Given {edge state} When {action} Then {handling}
#### Scenario 3: {Error case title}
Given {context} When {invalid action} Then error "{message}"
---
## Story 2: {Title}
{Repeat structure...}
---
## Out of Scope
- {Explicitly excluded items}
## Dependencies
- **Upstream:** {What must be done first}
- **Downstream:** {What depends on this}
## Domain Context
**Module:** {module} **Related Feature:** {feature doc path} **Entities:** {Entity1}, {Entity2} **Business Rules:** {BR-XXX references}
## Technical Notes
- {Implementation hints if needed}
## Validation Summary
**Validated:** {date}
### Confirmed
- {decision}: {user choice}
### Action Items
- {follow-up if any}
Anti-Patterns to Avoid
| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| Horizontal slicing | "Backend story" + "Frontend story" = delays value | Vertical slice: thin end-to-end functionality |
| Single scenario | Missing edge/error cases | Minimum 3 scenarios: happy, edge, error |
| Vague criteria | "Fast", "user-friendly" untestable | Quantify: "< 200ms", "≤ 3 clicks" |
| Solution-speak | "Use Redis cache" constrains team | Outcome: "Results return within 200ms" |
| Effort >8 | Won't fit sprint, hard to estimate | Apply SPIDR, split until ≤8 |
| No error scenario | Missing negative test coverage | Always include invalid input handling |
| Generic persona | "As a user" too vague | Specific: "As a hiring manager" |
Quality Checklist
Before completing user stories:
- [ ] Each story follows "As a... I want... So that..." format
- [ ] SPIDR splitting applied (effort ≤8, prefer ≤5)
- [ ] At least 3 scenarios per story: happy, edge, error
- [ ] All scenarios use GIVEN/WHEN/THEN format
- [ ] Effort estimated in Fibonacci (1, 2, 3, 5, 8)
- [ ] Stories independent (can develop in any order)
- [ ] Out of scope explicitly listed
- [ ] Dependencies identified (upstream/downstream)
- [ ] Parent PBI linked in frontmatter
- [ ] Domain vocabulary used correctly (if BravoSUITE)
- [ ] Validation interview completed
Validation Step (MANDATORY)
After creating user stories, validate with user.
Question Categories
| Category | Example Question |
|---|---|
| Slicing | "Are the story slices independent enough?" |
| Size | "Any story >8 effort that needs further splitting?" |
| Scenarios | "Any acceptance criteria missing for edge cases?" |
| Dependencies | "Are there hidden dependencies between stories?" |
| Scope | "Should anything be explicitly excluded?" |
Process
- Generate 2-4 questions focused on slicing quality, scenarios, and dependencies
- Use
AskUserQuestiontool to interview - Document in story artifact under
## Validation Summary - Update stories based on answers (split if needed)
This step is NOT optional.
Related
| Type | Reference |
|---|---|
| Role Skill | business-analyst |
| Command | /story |
| Input | /refine output (PBI) |
| Next Steps | /test-spec, /design-spec, /prioritize |
Triggers
Activates on: story, user story, user stories, slice, slicing, split story, breakdown
Task Management Protocol: - Always plan and break work into many small todo tasks - Always add a final review todo task to verify work quality and identify fixes/enhancements