A user story describes a piece of work from the point of view of the person who wants it, usually written as "as a [role], I want [thing], so that [benefit]". The point is to keep the reason attached to the work, so whoever builds it can make the small decisions in favour of the right thing.
The format is not the point
The "as a / I want / so that" template is a prompt, not a standard. A story written to the template with no acceptance criteria and no context is worse than a plain sentence with both. What makes a story useful is that it names who benefits, states what has to be true when it is finished, and carries enough context that someone who was not in the room can start.
What a good story contains
A story a developer can pick up without asking a question first generally has all of these.
- A user and a benefit
- Who is better off, and how. This is what lets someone make a judgement call mid-build.
- Acceptance criteria
- Specific, testable conditions for done. See acceptance criteria.
- Context
- The constraint that was mentioned, the decision already taken, the design it belongs to. Usually the part that gets left out.
- A size
- An estimate or story-point value, so it can be planned against.
- A type
- Feature, bug, chore or spike. Different kinds of work are triaged differently.
Why stories written from memory are thin
Nobody writes a bad ticket on purpose. They write it two days after the call, from a half-memory, for people who were not there - and they write nineteen of them in an afternoon, so the last few are thinner than the first few. The missing part is almost never the requirement; it is the reasoning and the constraints around it, which existed clearly in the conversation and never made it into the text.
Stories versus tasks versus epics
A story is a change in what a user can do. A task is a step in delivering it, meaningful only to the team. An epic is a container for related stories, useful for reporting and harmful when it becomes a place to put work nobody has scoped. Trackers name these differently - Jira has issue types and sub-tasks, Linear has issues and sub-issues, Shortcut has stories and epics - but the distinction survives the renaming.
Frequently asked questions
How small should a user story be?
Small enough to finish inside one iteration and still be independently valuable. If it cannot be both, it is usually two stories or an epic.
Can a bug be a user story?
It can be written as one, but there is little benefit. A bug needs reproduction steps and expected behaviour, which is a different shape from a story.
Can AI write user stories?
It can write a solid first draft, and the quality depends almost entirely on what it is given. A story generated from a transcript alone repeats the conversation; one generated with the docs, designs and codebase available can reference the real system. Either way a person should approve it - a generated story nobody has read is a liability rather than a saving.
How Spectr helps
Write user stories your developers can actually start
Draft stories with real acceptance criteria, then approve, edit or reject each one
Related terms
Spend less of the week on documents
Spectr drafts the spec, the requirement document and the stories from your meetings. You review and approve.
Free plan available. 30-day free trial on Starter.