Turn a validated user need into a small, testable unit of product learning and delivery.
“As a user, I want a feature” is rarely enough to build the right thing. A useful story identifies a real actor and situation, the outcome they need, rules and examples, boundaries, quality constraints, dependencies, and how the team will know the outcome works.
Start from observed user work
Name a meaningful role only when its goals or permissions differ. Describe the trigger, current workaround, desired progress, stakes, and environment. Link the story to research or support evidence. Do not disguise a stakeholder solution or technical task as a user need.
Give the team enough context
- Actor, situation, trigger, goal, and reason
- Current behavior, pain, frequency, and evidence
- Rules, terminology, permissions, and data
- Happy path, alternatives, empty states, errors, and recovery
- Accessibility, privacy, security, performance, and analytics needs
- Acceptance examples, dependencies, open questions, and owner
Separate related artifacts
| Artifact | Purpose | Example |
|---|---|---|
| User story | Frame a small valuable outcome | Member can recover account access |
| Task | Work needed to deliver it | Configure email delivery |
| Acceptance criterion | Observable boundary | Expired link produces a safe new-request route |
Refine a story collaboratively
- State the user outcome in plain language.
- Walk through a real example.
- List decisions, rules, and failure states.
- Split by independently valuable behavior.
- Write testable acceptance examples.
- Confirm readiness without freezing discovery.
Avoid story-shaped requirements debt
- One “user” representing incompatible audiences
- A story spanning an entire product area
- Acceptance criteria specifying only button clicks
- Ignoring operational and administrative users
Use a practical story record
Capture title, outcome statement, linked evidence, context, rules, examples, acceptance criteria, quality needs, dependencies, open decisions, design reference, analytics hypothesis, owner, and completion notes. Archive obsolete stories without treating the backlog as permanent product documentation.