user-story-fundamentals

When to use

• Writing backlog items.
• Turning requirements into user-centered work.
• Defining acceptance criteria.
• Splitting oversized product work.

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 that clause.
• 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.

Output

As a [user],
I want [capability],
so that [benefit].

- Given [context], when [action], then [outcome].

- Dependencies:
- Non-goals:
- Estimate: