Agile guide · Agile practices
User Stories: How to Write Them, With Templates and Examples
A user story is a short, plain-language description of something a user needs, written from their point of view. It captures who wants it, what they want and why, and acts as a placeholder for a conversation about the detail rather than a full specification.
Key takeaways
- A user story states who needs something, what they need and why.
- Acceptance criteria make each story testable; the Definition of Done applies to all stories.
- Use INVEST to check quality and split stories that will not fit in a sprint.
- Stories are a starting point for conversation, not a full specification.
The user story template
The most common format is: As a [type of user], I want [some goal] so that [some benefit].
- Who: a specific user or role, not "the system".
- What: the goal or capability they need, not the technical solution.
- Why: the benefit, which helps the team find the simplest way to deliver it.
Many teams describe a story as three Cs: the card (the short written story), the conversation (the discussion that fills in the detail) and the confirmation (the acceptance criteria that show it is done).
Acceptance criteria
Acceptance criteria are the conditions a story must meet to be accepted. They make the story testable and reduce misunderstandings. Two common styles:
- Checklist: "Booking shows the class time and location"; "Member receives a confirmation email".
- Given-When-Then: "Given a class has free places, when a member taps Book, then a place is reserved and the free places count falls by one."
The INVEST checklist
| Letter | Meaning | Question to ask |
|---|---|---|
| I | Independent | Can it be delivered without waiting for another story? |
| N | Negotiable | Is the detail open to discussion rather than fixed? |
| V | Valuable | Does it deliver value to a user or the business? |
| E | Estimable | Does the team understand it well enough to estimate it? |
| S | Small | Can it be finished within one sprint? |
| T | Testable | Are there clear acceptance criteria? |
How to write a user story, step by step
- Identify the user and their goal, ideally from research or real feedback.
- Write the story using the template, keeping it to one or two sentences.
- Add three to six acceptance criteria.
- Discuss it with the team during backlog refinement and adjust it.
- Check it against INVEST; split it if it is too big.
- Estimate it, for example with story points.
- Order it in the product backlog by value, risk and dependencies.
Examples: weak and improved
| Weak story | Improved story |
|---|---|
| As a user, I want a database table for bookings. | As a member, I want to book a class so that my place is reserved. |
| As the system, I want to send emails. | As a member, I want a booking confirmation email so that I have a record of my class. |
| As a user, I want the site to be fast. | As a mobile user, I want the timetable to load in under two seconds so that I can book on the go. |
| As an admin, I want a reports module with 15 reports. | As a gym manager, I want to see weekly attendance per class so that I can adjust the timetable. |
Full example: As a member, I want to join a waiting list when a class is full so that I can get a place if someone cancels. Acceptance criteria: the Join waiting list button appears only when a class is full; the member sees their position; when a place frees up, the first person is offered it by email and has two hours to accept.
Common mistakes
- Writing technical tasks disguised as stories.
- Stories so large they span several sprints; treat these as epics and split them.
- No "so that" clause, which hides the real need.
- Treating the story as a contract instead of starting a conversation.
- Missing or vague acceptance criteria, which lead to rework.
- Writing every story in the template even when a plain sentence would be clearer.
Free templates for this topic
Frequently asked questions
What is a user story in Agile?
A short description of a user need, written from the user's point of view, that the team turns into working functionality.
What is the user story format?
As a [type of user], I want [goal] so that [benefit].
Who writes user stories?
Anyone can write them, but the product owner is usually responsible for making sure they are clear and ordered in the backlog.
Are user stories part of Scrum?
No. The Scrum Guide talks about Product Backlog items; user stories are a popular way of writing them.
What are acceptance criteria in user stories?
Specific, testable conditions a story must meet to be accepted, often written as a checklist or in Given-When-Then form.
How small should a user story be?
Small enough to finish within one sprint, and ideally within a few days.
What does INVEST stand for in user stories?
Independent, Negotiable, Valuable, Estimable, Small and Testable.
What is the difference between a user story and a requirement?
A traditional requirement specifies what the system must do in detail; a user story describes a need and invites conversation to agree the detail. See project requirements.
What is the difference between a user story and an epic?
An epic is a large body of work made of many stories; a story fits in a single sprint.
How do you estimate user stories?
Most teams use relative sizing such as story points or T-shirt sizes, agreed together by the team.
Can user stories be used outside software?
Yes. Marketing and other teams write stories such as "As a prospective customer, I want a pricing comparison so that I can choose a plan"; see Agile marketing.