Pre-sprint quality brief · User Stories & AC
User Story Scorecard
As a [persona], I want [goal], so that [benefit].
I
Independent
Can it ship without another story being live first?
Story A blocks Story B — forces sequential scheduling
N
Negotiable
Are the details still open for conversation?
Story treated as a fixed spec; team rubber-stamps it
V
Valuable
Does completing it deliver something a user cares about?
"Set up DB schema" written as a user-facing story
E
Estimatable
Does the team know enough to size it?
Too vague, or too large to estimate confidently
S
Small
Is it completable within one sprint?
"Build the user profile system" = epic in disguise
T
Testable
Can someone write a failing test for this?
"The UI should feel intuitive" — untestable
Bullet Checklist
✓ Use when
Simple CRUD, clear happy path, shared team context [6]
✗ Skip when
Multiple conditional branches exist
- Reset link within 2 min
- Link expires in 24 h
- Password: ≥8 chars, ≥1 uppercase
- Auto-login after reset
Given / When / Then
✓ Use when
Complex logic, BDD automation, multi-path flows [5]
✗ Skip when
Overkill for a single-outcome field validation
Given valid "SAVE20" + $100 cart
When applied
Then $20 discount in summary
Rules-based
✓ Use when
Business constraints, integration boundaries, compliance [4]
✗ Skip when
Scenarios flow naturally as Given/When/Then
If payment fails → alert billing
If 3 failures → lock account
If fraud flag → manual review
1
3–5 per story. More than 6 means the story is an epic — split it first.
2
Measurable. "loads < 2 seconds" not "loads fast". Must yield a Yes/No answer.
3
One condition per criterion. No AND/OR conjunctions inside a single line.
4
Cover edge cases. Empty state, error state, permission boundaries.
5
Include non-functionals. Performance, security, accessibility — never assume implied.
6
Written before dev starts — not as an afterthought when QA asks for test cases.
Workflow steps
Story spans a sequential process
Draft → review → approve → publish
Draft → review → approve → publish
CRUD operations
Multiple actions on one entity
Create / edit / delete account
Create / edit / delete account
Business rule paths
Different rule branches in one story
Date range / weekend / ±N days
Date range / weekend / ±N days
Data variations
Multiple input types need different handling
PDF first, then images, then XLSX
PDF first, then images, then XLSX
Happy path first
Edge cases dominate complexity
Basic login → 2FA → lockout
Basic login → 2FA → lockout
User roles
Different access levels need different UX
Admin view → manager → employee
Admin view → manager → employee
Interface / platform
Multiple delivery channels
Web first → mobile push
Web first → mobile push
Defer performance
Speed optional for v1
"Search works" → "search < 1s" next sprint
"Search works" → "search < 1s" next sprint
Spike
Unknown implementation approach
Time-boxed investigation story
Time-boxed investigation story
Three Amigos
30–45 min before refinement — surface misunderstandings when a conversation is cheap [9]⚖
Product Owner
Is this story delivering the right value? Does the AC match actual user intent?
⚙
Developer
Is this technically feasible? What constraints might change the design?
✎
Tester
Can I write tests for this? What scenarios are missing from the AC?
Definition of Ready
All boxes must pass before pulling into sprint planning [10]- Written in the agreed user story format
- AC defined, measurable, and agreed by the whole team
- INVEST-compliant: no blocking dependencies, fits within one sprint
- UI/UX designs attached (if UI-facing)
- External dependencies (APIs, services, data sources) identified
- Estimated (story points or T-shirt size)
- No open questions that would block development once sprint starts
| Anti-pattern | Bad example | Fix |
|---|---|---|
| System as actor | "The API should validate the email format" | "As a user, I want inline email validation feedback" |
| Epic as story | "Build the entire checkout flow" | Split by workflow steps into 4–6 stories |
| Vague AC | "Should feel intuitive" / "be accessible" | Replace with a measurable, yes/no-testable outcome |
| AND-heavy AC | "User can search, filter, and sort results" | One criterion per capability |
| Missing "so that" | "As a user, I want a dashboard" | Add the benefit — it reveals whether the story is actually correct |
| AC as implementation | "Back-end should use Redis for session caching" | Describe observable behavior, not the chosen solution |
| Too many AC | 10+ criteria on a single story | Story is an epic — split it before estimating |