Delivery
User story template
The story sentence, acceptance criteria written as Given, When and Then, the dependencies that could hold it up, and a ready check the team runs before the item can be selected.
What it is
A user story is a placeholder for a conversation. The familiar sentence names who wants something, what they want and why, and the acceptance criteria say how the team will know it is done. Kent Beck introduced stories on the C3 project, and Ron Jeffries later described them as card, conversation and confirmation, which is still the most useful summary of what they are for.
The format is not the point and the conversation is. A team that writes perfect sentences and never discusses them has a backlog of small documents. A team that talks and then writes down what it agreed has a backlog it can work from.
Acceptance criteria carry most of the value. Written before the work starts they catch the disagreement while it is still cheap. Written afterwards they describe whatever got built.
When to use it
- You are breaking a larger piece of work into items a team can finish inside a Sprint.
- The team keeps discovering what an item meant halfway through building it.
- Testers and developers are working from different ideas of done.
- You want each item to carry the reason for it, so it can be dropped when the reason goes away.
What is in it
- The story
- Why now
- Acceptance criteria
- Out of scope for this item
- Dependencies and constraints
- Ready check
- Done check
The template
The story
One sentence. Who it is for, what they want to do, and what it gets them. If you cannot name the person, the item may be a technical task, and it should be written as one rather than dressed as a story.
As a [role], I want to [do the thing], so that [outcome they get].
For example, as an account admin, I want to import seats from a CSV, so that I do not rebuild permissions by hand for every new starter.
Why now
Two lines on the evidence and the timing. What made this item rise to the top of the list this Sprint rather than next quarter.
Acceptance criteria
Write each one as Given, When, Then, and keep it to observable behaviour. Include at least one unhappy path, because that is the one that comes back in review.
- Given a CSV of 50 valid rows, when the admin uploads it, then 50 invitations are queued and a summary appears within 10 seconds.
- Given a CSV where one row has an invalid email address, when the admin uploads it, then the valid rows are still queued and the invalid row is listed with its line number.
- Given a CSV above the 5,000 row limit, when the admin uploads it, then nothing is queued and the message names the limit.
Out of scope for this item
What a reviewer will expect to see and will not find. One line each.
Dependencies and constraints
| What | Who holds it | Needed by |
|---|---|---|
| Rate limit on the invitations endpoint | Platform team | Before the item is selected |
Ready check
The team runs this before the item can be selected. An item that fails a line goes back to refinement rather than into the Sprint.
- The outcome it serves is named and still current
- Acceptance criteria cover at least one failure case
- Every dependency has an owner and a date
- Design is attached, or the team has agreed it is not needed
- The Developers can size it without a further conversation
Done check
- All acceptance criteria pass
- Meets the Definition of Done, including the parts about tests and instrumentation
- The measure named under why now is instrumented and reporting
Questions people ask
- Does every backlog item have to be a user story?
- No. Technical work, spikes and defects often have no user in the sentence, and inventing a persona to fit the format hides who actually asked. Write those plainly and keep the story format for changes a user will notice.
- How small should a story be?
- Small enough to finish comfortably inside a Sprint, and large enough to be worth delivering on its own. If it would take most of the Sprint, splitting it usually finds something smaller worth having sooner.
- Who writes the acceptance criteria?
- The Scrum Team, together, before the work starts. The Product Owner brings the intent and the developers bring the cases nobody had thought of.
- What about the INVEST checks?
- They are a good test after the fact. Independent, negotiable, valuable, estimable, small and testable. Run them over an item that feels wrong and one of the six usually explains why.