flpbalada User Story Fundamentals
Goal
Describe who needs what and why. Make completion testable.
Story Format
As a [user type],
I want [capability],
so that [benefit].
Rules
- Name a real user or actor.
- Describe capability, not implementation.
- State value in the
so thatclause. - Add acceptance criteria.
- Keep stories small enough for one sprint.
- Split stories that are too large, vague, or dependency-heavy.
- Separate acceptance criteria from definition of done.
INVEST Check
- Independent: can be delivered separately.
- Negotiable: details can change.
- Valuable: clear user or business value.
- Estimable: team can size it.
- Small: fits a sprint.
- Testable: clear pass/fail criteria.
Acceptance Criteria
Use concrete Given/When/Then statements:
Given [context],
when [action],
then [outcome].
Cover:
- Happy path.
- Empty or missing data.
- Invalid input.
- Permission or role differences.
- Error states.
Splitting Methods
- Workflow step.
- User role.
- Data operation: create, read, update, delete.
- Happy path then edge cases.
- Platform or channel.
- Permission level.
- Release slice.
Resources
- User Stories Applied - Mike Cohn
- User Story Mapping - Jeff Patton
- Writing Effective User Stories - Scrum Alliance
Output
As a [user],
I want [capability],
so that [benefit].
- Given [context], when [action], then [outcome].
- Dependencies:
- Non-goals:
- Estimate: