How to Write User Stories: Template, Examples, Criteria
Short answer
Write a user story as "As a [role], I want [goal], so that [benefit]", then add three to seven acceptance criteria a tester can check with yes or no. Good stories pass the INVEST test: independent, negotiable, valuable, estimable, small and testable. Split stories that are too big along workflow steps, business rules, data variations or quality levels.
Most weak user stories are tasks wearing a costume. “As a developer, I want to migrate the database” has the right shape and no user, no benefit. The team knows what to do afterwards. Nobody knows why.
The format is younger than many people assume. According to the Agile Alliance, the “As a… I want… so that…” template was created in 2001 at Connextra, a UK company. That same year, Ron Jeffries, one of the founders of Extreme Programming, described a story’s three parts as card, conversation and confirmation. The card is just a reminder. The real requirement takes shape in the conversation and gets confirmed through acceptance tests.
That second and third part is where most teams cut corners.
The template has three parts, not one
A complete user story has three building blocks:
- The story: “As a [role], I want [goal], so that [benefit].”
- Acceptance criteria: testable conditions that define when the story is done.
- Notes from the conversation: assumptions, sketches, open questions, links.
Here is an example from a customer portal for a UK broadband provider:
As a customer on a monthly contract, I want to schedule an engineer visit online, so that I don’t have to wait on hold for the phone line.
Its acceptance criteria:
- The customer sees available slots for the next 14 days, in two-hour windows.
- Slots already full are shown greyed out, not hidden.
- Booking a slot sends a confirmation email within five minutes.
- The customer can cancel up to 24 hours before the slot without calling.
- Customers with an open fault ticket see the ticket number on the booking page.
Five criteria, each checkable with yes or no. A tester doesn’t need to ask anyone.
Acceptance criteria in Given-When-Then format
When rules depend on conditions, the Given-When-Then format from behaviour-driven development keeps things readable:
| Given | When | Then |
|---|---|---|
| the next free slot is in 3 days | the customer opens the booking page | the earliest selectable date is 3 days out |
| the customer has a slot booked for tomorrow 10:00 | they try to cancel at 11:00 today | cancellation is blocked and a support number appears |
| the customer’s account is in arrears | they open the booking page | booking is disabled and a payment link is shown |
Each row doubles as a test case. Teams with automated testing can turn tables like this into test code almost directly.
The INVEST check
Bill Wake summed up six qualities of a good story in 2003, and Mike Cohn spread them a year later in his book User Stories Applied. The list works as a gate before a story goes into planning.
- Independent: Can it be built and shipped without waiting for another story?
- Negotiable: Is the how still open, or does it already prescribe a solution?
- Valuable: Does a user or the client get something if only this story ships?
- Estimable: Can the team size it roughly?
- Small: Does it fit in a sprint, ideally two or three working days?
- Testable: Are there acceptance criteria you can check with yes or no?
“Independent” is the hardest one in practice. Truly independent stories are rare, and that’s fine. Flexible ordering is enough.
Four ways to split a big story
“As a customer, I want to pay online” is an epic. It fits no sprint. These cuts nearly always work:
- By workflow step: view the invoice as PDF, then pay by card, then receive a receipt.
- By business rule: standard payment first, edge cases like part-payments or credit notes later.
- By data variation: card first, then PayPal, then bank transfer.
- By quality level: a simple version for 100 users now, performance work for 10,000 later.
Every slice must deliver value on its own. “Build the payment backend” and “build the payment frontend” are not stories; they’re technical tasks. Slice horizontally by layer and you finish the sprint with nothing a user can try.
Which cut is right depends on value. If most of your customers already pay by card, the card story alone is a releasable increment, and other payment methods can wait until somebody asks.
What weak stories look like
You can spot most problems in the first sentence.
| Weak | Better |
|---|---|
| As a user, I want to log in. | As a field technician, I want to sign in with my fingerprint, so that I don’t type a password in front of the customer. |
| As an admin, I want a dashboard. | As a team lead, I want to see open tickets per person every Monday, so that I can rebalance the workload. |
| As the system, I want to sync data. | As a dispatcher, I want order changes from the ERP within five minutes, so that I don’t plan routes on stale data. |
The pattern: make the role as specific as possible, describe an activity rather than a screen, and let the benefit say what goes wrong without the feature. The benefit clause matters most. It’s what you’ll lean on when you prioritise with MoSCoW, because it shows what is at stake.
How detailed must stories be for estimation?
Epics are enough for a rough budget. Sprint planning needs stories the team can size, for example with story points. Here is a practical rule: if team members’ estimates for one story range from 3 to 13 points, the story is still unclear or too big.
Stories don’t cover everything. Response times, privacy rules, browser support and integrations sound awkward as “As a… I want…”. Put them in a short companion document based on a software requirements document template, or in the team’s Definition of Done.
If you’re building with an external team, write the first ten to twenty stories together. Studios such as OnlineBuilders treat that joint clarification as part of project kick-off, and it saves arguments at acceptance time.
From backlog to sign-off
Good acceptance criteria pay off at the end. When every story has checkable criteria, acceptance becomes a checklist instead of a negotiation. The criteria feed straight into your user acceptance testing checklist, and disputes over what “done” means become rare.
Next step: take the five most important items in your backlog and run each through the INVEST list. Where the “so that” clause or the acceptance criteria are missing, add them today, before the team estimates.
Questions people ask
Who writes user stories in Scrum?
The product owner is accountable for the backlog, but anyone can write a story, including people from sales or support. What matters is the conversation between the business and the developers before work starts.
How many acceptance criteria should a user story have?
Three to seven is a sensible range. More than ten usually means the story is too big and should be split.
What is the difference between an epic and a user story?
An epic is a story too large for one sprint, such as "customers can pay online". You break it into several user stories, each deliverable in a few days.
Can user stories replace a requirements document?
Partly. Functional requirements map well to stories. Non-functional requirements such as response times, privacy rules and supported browsers fit better in a short companion document or the team's Definition of Done.
