User Stories and INVEST
Short, simple descriptions of a feature told from the user’s perspective. The primary way backlog items are written in Scrum.
Format
As a <user role>, I want <action> so that I can <value/benefit>.
A user story has three elements:
- User — who the story is for
- Action — what they want to do
- Benefit — the value they get
Key elements of a good user story
- User persona — who it’s for (not a vague “user”)
- Definition of Done — clear acceptance criteria
- Tasks required — what needs to be built
- Relevant user feedback — any evidence shaping the story
INVEST criteria
Good user stories meet all six criteria:
- I — Independent. The story can be started and finished by itself; not dependent on another story.
- N — Negotiable. There’s room for negotiation with the Product Owner on the details.
- V — Valuable. Completing the story delivers value to the user.
- E — Estimable. The team can estimate effort; the definition of done is clear.
- S — Small. Each story fits in a single Sprint. If too big, it should be broken down.
- T — Testable. A test can verify whether acceptance criteria are met.
Epics
An epic is a group or collection of user stories — too big for one sprint, representing a larger feature or goal. Epics are broken down into smaller user stories that satisfy INVEST.
Acceptance criteria
The checklist used to decide whether the user story is done. Each story should have explicit criteria — ideally written before development starts, so “done” isn’t ambiguous. Acceptance criteria feed into the team’s broader Definition of Done.
Application
- User stories are the primary content of the Product Backlog.
- The Product Owner is accountable for writing/refining them; the whole team helps.
- During backlog refinement, stories that fail INVEST (especially “S” and “E”) get split or clarified.
Connections
- scrum-framework — where user stories live (backlog, sprint planning)
- agile-manifesto
- course-5-agile-project-management