A user story is a brief, plain-language requirement written from the point of view of the person who wants it, commonly in the form: As a type of user, I want a goal so that a benefit.
Why it matters
Stories keep the focus on the user's problem rather than the technical solution, and they are small enough to plan and build within a sprint. Paired with acceptance criteria, they give the team a shared definition of done. Many teams check stories against the INVEST guideline: independent, negotiable, valuable, estimable, small and testable. Conversations around the story matter as much as the sentence itself.
Example
As a shop owner, I want to export orders as a CSV file so that I can send them to my accountant. Acceptance criteria: export includes date, order number and total; a month can be selected; the file downloads in under 10 seconds.
Common mistakes
- Writing technical tasks and calling them stories.
- Leaving out the benefit, so the team cannot judge priority.
- Making stories so big they cannot finish in one sprint.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.