User story template with acceptance criteria
A good user story tells an engineer who it's for, what they need and why, and exactly how everyone will know it's done. This template covers all four, with examples you can copy.
Updated
The short answer
A user story follows the format "As a [type of user], I want [goal], so that [benefit]", followed by acceptance criteria that define done. Write acceptance criteria as Given / When / Then scenarios, and check the story against INVEST: independent, negotiable, valuable, estimable, small and testable.
Pastes with formatting into Google Docs, Word, Notion and Confluence.
[Short title]
As a [type of user] I want [goal] So that [benefit]
Epic: [epic name] | Estimate: [points] | Priority: [High/Medium/Low]
Acceptance criteria
Scenario 1: [name]
- Given [starting situation]
- When [action]
- Then [expected result]
Scenario 2: [name]
- Given
- When
- Then
Notes
- Designs: [link]
- Out of scope:
- Dependencies:
INVEST check
- Independent: can be built without waiting on another story
- Negotiable: describes the need, not a fixed solution
- Valuable: a user or the business benefits
- Estimable: the team can size it
- Small: fits in one sprint
- Testable: the acceptance criteria can be checked
Example: fictional Meridian Labs data
Build a dashboard from a template
As a team lead at a Meridian Labs customer I want to start a dashboard from a ready-made template So that I can answer my team's product questions without waiting for the data team
Epic: Dashboard builder | Estimate: 5 points | Priority: High
Acceptance criteria
Scenario 1: Create from a template
- Given I'm on Pulse Analytics with at least one data source connected
- When I choose "New dashboard" and pick "Daily active teams"
- Then a dashboard opens with that template's charts, using my team's data
Scenario 2: No data yet
- Given my workspace has no events in the last 7 days
- When I pick a template
- Then I see a message explaining that data appears once events arrive, with a link to the setup guide
Notes
- Designs: Kai Lindqvist, Figma (link)
- Out of scope: exporting dashboards (decided: ship templates before exports)
- Dependencies: Event schema contract, owned by Tom Reyes (4 days overdue)
INVEST check
- Independent: can be built without waiting on another story
- Negotiable: describes the need, not a fixed solution
- Valuable: a user or the business benefits
- Estimable: the team can size it
- Small: fits in one sprint
- Testable: the acceptance criteria can be checked
New to user stories? Start here
What it is
A user story describes a small piece of functionality from the point of view of the person who'll use it, plus the conditions that prove it's done. It's how big ideas get broken into work a team can finish in one sprint.
Use it when
- Breaking an epic into sprint-sized work
- Refining the backlog before sprint planning
- Handing work to engineers and testers
Who writes it
The product manager or product owner, refined with engineers
Who reads it
Engineers and testers
How to fill it in
- 1As a / I want / So that
- Name a specific kind of user, not "the user". The "so that" is the most important line; if you can't write it, question the story.
- 2Epic
- The larger body of work this belongs to, so the story has context.
- 3Acceptance criteria
- One scenario per behaviour. Include the unhappy path, such as errors and empty states.
- 4Out of scope
- Stops the story quietly growing during the sprint.
- 5INVEST check
- If a box won't tick, split or rewrite the story before planning.
Example
Title: Save a dashboard view
As a team lead, I want to save my dashboard filters as a named view, so that I can see my team's numbers without setting filters every morning.
- Scenario 1: Save a view. Given I've set filters on a dashboard, When I choose Save view and enter a name, Then the view appears in my saved views with those filters.
- Scenario 2: Name already used. Given I have a view called "My team", When I save another view with that name, Then I'm asked to choose a different name.
Common mistakes
- Writing tasks as stories: "Set up the database" is a task, not a story.
- Leaving out the "so that", which removes the reason the story exists.
- Stories too big for one sprint. Split by scenario or by user type.
Story in a ticket tool
- The "why" stops at the ticket
- No link to the milestone or objective it serves
Story in Ondule
- Sits under its epic, milestone and objective
- Blocked-by links shown on the ticket
- Progress rolls up to the roadmap automatically
How to do this in Ondule
Questions
- What is the format of a user story?
- "As a [type of user], I want [goal], so that [benefit]", followed by acceptance criteria.
- What are acceptance criteria?
- The conditions a story must meet to be done, usually written as Given / When / Then scenarios that can be tested.
- What is the difference between a user story and an epic?
- A story is small enough to finish in one sprint. An epic is a larger body of work made up of many stories.