User story
Also called story.
A short description of a feature from the point of view of the person who needs it, and why they need it.
Last updated
What it is.
The common template is: as a [type of user], I want [to do something], so that [I get some benefit]. The "so that" matters most, because it tells the team what problem they are really solving.
A story is a placeholder for a conversation, not a full spec. The details go into acceptance criteria underneath it. Good stories are small enough to finish in one sprint and give some value on their own.
Why it matters
Stories keep the team focused on users and outcomes rather than technical tasks. They are easy to order in a backlog, easy to estimate, and easy for non-technical stakeholders to read and challenge.
In a product build
Stories are how a discovery scope turns into a backlog. Each milestone in a product build is a group of stories, each with its own acceptance criteria.
Common mistakes.
- 01
Writing technical tasks as stories ("as a developer, I want a database table").
- 02
Stories so large they take several sprints. Split them by user step or by case.
- 03
Dropping the "so that", which leaves the team guessing at the goal.
Related terms.
- Acceptance criteriaThe testable conditions a feature must meet before the person who asked for it accepts it as done.
- Backlog (product backlog)The ordered list of everything still to be built or fixed in a product, with the most important work at the top.
- SprintA fixed time box, one month or less and often two weeks, in which a team builds and shows a working piece of the product.
- VelocityThe amount of finished work a team completes in a sprint, used to forecast how much fits in the time left.
Guides and pages
Browse the full glossary or read answers to common questions.
