User story template and acceptance criteria
The classic user story template with a copy-paste card, the variants worth knowing, and one worked example carried from template to acceptance criteria to estimate.
The user story template is one sentence with three blanks:
As a [role], I want [goal], so that [benefit].
Copy it, use it, but know what it’s for: the template is a prompt for a conversation, not a form to complete. A filled-in sentence is where refinement starts. What makes the story workable is what gets attached next — the acceptance criteria that turn an agreed intention into a pass/fail test, and the estimate that turns it into plannable work. This chapter carries one story through all three.
Filling the blanks without faking them
Each slot has a common misfire, and each misfire is checkable:
- [role] — a specific person, never “a user.” If you couldn’t pick this person out of your analytics or your support queue, the role is decoration. Test: could a designer make one decision differently because of the role you chose?
- [goal] — what the person does, in their vocabulary. “I want to reset my password” belongs to the user; “I want a password-reset microservice” belongs to the architecture diagram. Test: would the person actually say this sentence?
- [benefit] — the argument for scheduling the work. Test: delete the clause. If nothing is lost, the benefit hasn’t been found yet.
The full reasoning behind the format — including the three Cs and the INVEST checklist a finished story should pass — is in what is a user story?. Sixteen worked instances, good and bad, are in user story examples.
A copy-paste story card
The sentence alone is not enough to take into a sprint. Here is the full card shape worth standardizing on — story, criteria, boundaries, and a size added last:
Story
As a [role], I want [goal], so that [benefit].
Acceptance criteria (3–5, each pass/fail)
- [ ] …
- [ ] …
- [ ] …
Out of scope
- What this story deliberately does NOT cover.
Notes & dependencies
- Designs, decisions, other teams, open questions.
Size: [added by the team, after the conversation — never before]Two deliberate choices in that card. “Out of scope” is load-bearing: most estimation arguments are two people sizing different scopes, and one line here prevents them. The size comes last: a number written on the card before the team discusses it becomes an anchor, which is the first of the classic planning poker mistakes.
Template variants
The classic template is the right default, and it isn’t the only shape that works.
| Variant | Shape | Reach for it when |
|---|---|---|
| Classic (Connextra) | As a [role], I want [goal], so that [benefit] | The default for user-facing work |
| Job story | When [situation], I want to [motivation], so I can [outcome] | The triggering moment explains more than the persona — the same person on a train wants different things than at a desk |
| Benefit-first | In order to [benefit], as a [role], I want [goal] | The team keeps writing circular benefits; putting the clause first makes it impossible to skip |
| Plain problem statement | One sentence of problem, one of outcome, plus “done when” criteria | Platform and technical work where the only honest persona would be the team itself |
The last row matters more than it looks. Some backlog items have no user in the sentence, and pretending otherwise produces filler like “as a developer, I want the framework upgraded.” The template’s discipline — a stated reason plus testable criteria — transfers to that work; the sentence costume doesn’t need to.
Acceptance criteria: the confirmation on the card
Acceptance criteria are the story’s pass/fail conditions, written before work starts. On the card they do two jobs: they capture what the refinement conversation actually agreed, and they define the finish line the estimate will be sizing toward. Two formats cover nearly every story:
A plain checklist, for independent conditions:
- Cart contents persist across sessions for 30 days.
- A returning shopper sees the cart from any signed-in device.
- An emptied cart stays empty (no resurrection of removed items).
Given/When/Then, for behaviour that depends on state:
- Given a shopper with a saved cart, When an item goes out of stock, Then the cart shows the item greyed out with an “out of stock” label rather than silently removing it.
Default to the checklist; reach for Given/When/Then when the precondition is doing real work. Keep the list to three to five entries — a longer list usually means the story should split, and the criteria are showing you the cut lines. For the full treatment (criteria vs requirements, criteria vs definition of done, who writes them), see the acceptance criteria chapter.
Worked example: one story, template to estimate
Here is the path a real story takes, using the card above.
Step 1 — the story. The product owner writes:
As a first-time buyer, I want to check out without creating an account, so that I can finish my purchase before I change my mind.
Step 2 — the conversation, captured as criteria. In backlog refinement the team surfaces the edges the sentence doesn’t carry, and writes them down:
- A buyer can complete checkout with only email and shipping details, no password.
- The order confirmation email offers account creation with one click (order already attached).
- A guest order is findable by support via the order number plus email.
- Guest checkout respects the same fraud checks as account checkout.
Out of scope: converting historical guest orders when an account is created later.
Step 3 — the readiness check. Four criteria, one named exclusion, no unconfirmed dependencies: the story passes the definition of ready and goes to the team for sizing.
Step 4 — the estimate. The team votes in a round of planning poker. Cards come up 3, 5, 5, 8. The 8 explains: the fraud-check criterion means touching the payments provider integration, which nobody else had priced in. That’s the criteria doing their real job — the discussion is about scope, not about whose number is right. The team re-votes and converges on 5.
Notice the direction of travel: criteria first, then points. A story estimated before its criteria exist produces the wide, unresolvable spreads that stall sizing sessions — the team is voting on different stories that happen to share a title.
Frequently asked questions
What is the user story template?
“As a [role], I want [goal], so that [benefit].” The role names who gets the value, the goal names the capability in that person’s terms, and the benefit is the reason the work deserves a place in the backlog. The template is a prompt for a conversation, not a form to complete — filling in the blanks is where refinement starts.
How do you write acceptance criteria for a user story?
Write three to five testable conditions that say, pass or fail, whether the story delivered what was agreed. Use a plain checklist when the conditions are independent, and Given/When/Then when the behaviour depends on state. Each criterion should be checkable by a tester who never attended the refinement conversation.
Should acceptance criteria use Given/When/Then or a checklist?
Match the format to the behaviour. Given/When/Then earns its keep when the outcome depends on a starting state, because it forces you to name the precondition, the trigger and the result. A checklist is faster to read and harder to pad when the story is simply “these four things must be true.” Most stories need only the checklist.
What is a job story?
A variant that replaces the persona with a situation: “When [situation], I want to [motivation], so I can [outcome].” Job stories come from the jobs-to-be-done school and work well when the triggering moment explains the requirement better than a persona does — the same person wants different things at their desk and on a train.
Does every backlog item need the user story template?
No. The template describes user-facing value, and forcing it onto platform work, known bugs or research spikes produces sentences that add ceremony without information. Keep the two disciplines that always transfer — a stated reason and testable acceptance criteria — and let the sentence shape fit the work.
Related reading
- Agile estimation: the complete guide — the hub for everything here.
- What is a user story? — the reasoning behind the template: the three Cs and INVEST.
- User story examples — sixteen annotated stories to calibrate against.
- Acceptance criteria: how to write them — the full chapter on the confirmation step.
- Definition of ready — the gate a templated story clears on its way into the sprint.
- What are story points? — the unit the finished card gets sized in.