Build · Core
Write user stories with acceptance criteria
User stories describe who needs something and why, so the team builds for a real need. Acceptance criteria say exactly when a story is done, so everyone agrees what to build and how to test it.
About 2-4 hoursEvergreenLast reviewed 4 November 2026
Who this applies to
- Skills it builds
- Delivery and executionCommunication and influence
- PM types
- All
- Product types
- All
- Starting points
- All
- Ways of working
- All
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- Break each roadmap item (epic) into small pieces of value a user would notice. Each story should be small enough to finish in a few days.
- Write each story as: 'As a [type of user], I want [to do something] so that [I get this benefit].' Use a real user group from your research, not just 'user'.
- Under each story, add 3 to 6 acceptance criteria. Write them as checks that are either met or not, for example 'It's done when the user can see their reference number', or as 'Given... when... then...'.
- Include criteria for errors and edge cases (what happens if the user enters something wrong) and for accessibility (for example, 'works using only a keyboard').
- Go through the stories with your engineers and tester before they are planned into work. Their questions will show you what is missing.
- Agree a team 'definition of ready': what a story needs before work starts, such as clear criteria, designs attached and dependencies known.
Intermediate (1 to 4 years)
- Split epics into thin, user-visible stories that each fit within a few days.
- Write the stories against real user groups, with testable acceptance criteria covering errors, edge cases and accessibility.
- Refine them with engineering and QA before planning, and attach designs.
- Agree and apply a definition of ready.
Experienced (5+ years)
- Keep stories small, valuable to users and independent where possible.
- Make acceptance criteria testable, covering unhappy paths and accessibility.
- Refine stories with the team, and attach designs and dependencies.
- Agree a definition of ready and use it.
Who can do this
Owner: Product manager
Can be delegated to
- Business Analyst or Product Owner: Draft stories and acceptance criteria for the PM to review
- QA / Tester: Add edge cases and test scenarios to the acceptance criteria
- Content Designer or UX Designer: Write the user-facing text the stories need
- Tech Lead or Backend Engineer or Frontend Engineer or Architect: Split stories so they can be built and released independently
Reviewed by: QA / Tester, Tech Lead, UX Designer
Tool examples
- Jira
- Set a description template for the Story work type with sections for the story, acceptance criteria and design links. Link each story to its epic.
- Azure DevOps
- Use the User Story work item. Put the criteria in the Acceptance Criteria field so they show up in test planning.
- Linear
- Use an issue template with headings for the story and acceptance criteria.
- Figma
- Paste a link to the exact frame each story covers, not the whole file.
- Claude
- Paste a draft story and ask for missing edge cases and error states. You decide which ones belong in this story.
- Copilot
- Ask it to suggest Given/When/Then criteria from your story, then check them with your tester.
Definition of done
- Each story names a real user group and a clear benefit
- Each story has testable acceptance criteria, including errors and accessibility
- Stories reviewed with engineering and QA before planning
- Definition of ready agreed by the team
Common pitfalls
- Writing technical tasks and calling them user stories
- Stories too big to finish in a sprint or a few days
- Criteria that describe the screen layout rather than the outcome
If you lead the team
What good looks like: Stories describe who needs something and why, with clear acceptance criteria.
Ask your PM
- Can the team explain why each story matters to a user?
- Are acceptance criteria agreed before work starts?
Warning signs
- Stories are technical tasks with no user.
- Arguments about 'done' are common.