A user story is a short description of a piece of work written from the perspective of the person who benefits from it, not from the perspective of the system. The classic format — as a [type of user], I want [goal], so that [reason] — looks almost too simple to matter, but the discipline it forces is real: naming a specific user and a specific reason keeps a backlog full of value statements instead of a list of technical tasks nobody outside engineering can evaluate.
What changed in 2026
- AI drafting tools got good at a first pass, not the last pass. Product teams now commonly generate a rough story draft from a feature idea or support ticket, then edit it down — the editing step, where a human checks the user and the reason are real, remains the part that matters.
- Acceptance criteria moved earlier in the process. More teams write acceptance criteria at the same time as the story rather than after, because AI coding assistants build closer to spec when the criteria exist upfront.
- Story-writing workshops got shorter and more frequent. Instead of one long backlog-grooming session, many teams write and refine stories continuously in smaller batches.
The format, and why each part matters
The standard template has three clauses, and each one is doing a specific job:
- As a [type of user] — forces you to name who benefits. "As a user" is a red flag; specify the role (new signup, returning customer, admin).
- I want [goal] — the capability itself, stated as an outcome, not an implementation ("I want to reset my password" not "I want a password field with a regex check").
- So that [reason] — the value. If you cannot fill in a real reason, question whether the story belongs in the backlog at all.
INVEST: the quality checklist
A well-known acronym for evaluating whether a story is actually ready to be worked on:
| Letter |
Stands for |
What it checks |
| I |
Independent |
Can be built and shipped without waiting on another story |
| N |
Negotiable |
Not a rigid spec; details can be discussed with the team |
| V |
Valuable |
Delivers value to a user or the business, not just to engineering |
| E |
Estimable |
The team knows enough to size it, even roughly |
| S |
Small |
Fits inside a single sprint, ideally a few days of work |
| T |
Testable |
Has a clear condition for done, usually acceptance criteria |
A story that fails two or more of these is usually not ready for sprint planning — it needs to be split, clarified, or researched further first.
Writing acceptance criteria
Acceptance criteria state the specific conditions a story must meet to be considered done. The most common format is Given/When/Then: given a starting state, when an action happens, then a specific result occurs. A login story might read: given a registered user on the login page, when they enter valid credentials, then they land on their dashboard. Write three to seven of these per story — fewer and the story is probably underspecified, more and the story is probably too big.
Stories vs epics vs tasks
Confusing these three is one of the most common backlog problems. An epic is a large body of work that spans multiple sprints and gets broken into several stories. A story is a single unit of user-facing value sized for one sprint. A task is an implementation step inside a story — "write the API endpoint," "add the database migration" — with no standalone value to a user. Tasks belong on a story checklist, not as their own backlog items competing for backlog priority.
FAQ
How big should a user story be?
Small enough to finish within a sprint, ideally within a few days. If a story cannot be estimated with any confidence, it is usually a sign it needs to be split or researched first.
Do all stories need acceptance criteria?
Yes, in practice. Even a simple story benefits from writing down what done means; it prevents disagreements about scope once work is already underway.
Who writes user stories?
Typically the Product Owner drafts them, often with input from developers and designers during backlog refinement. The whole team should feel able to question or refine a story before it enters a sprint.
What is a common mistake in writing user stories?
Writing the solution instead of the need. A story that specifies implementation details ("add a dropdown with these five options") removes the negotiation that makes stories useful in the first place, and quietly turns a story into a spec.
Where to go next