User stories: a beginner’s guide to acceptance criteria
22 September 2010 (Last updated 1 November 2021)
Acceptance criteria define what must be done to complete an Agile user story. They specify the boundaries of the story and are used to confirm when it is working as intended. Here’s an introductory guide to writing and using acceptance criteria.
Acceptance criteria checklist
Discover the 13 features of effective acceptance criteria
Make sure your acceptance criteria deliver valuable user stories, and a valuable product.
Last week I described the bones of the user story in the first post of our introductory series on user stories. Briefly, a user story is a description of an objective a person should be able to achieve when using your website/application/software. These stories are often written in this format: As an [actor] I want [action] so that [achievement].
For example: As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.
This post adds some flesh to the idea of user stories, in the shape of acceptance criteria.
Where are the details?
At first glance, it can seem as if user stories don’t provide enough information to get a team moving from an idea to a product. That’s where acceptance criteria come in. But first, here’s some background. In 2001, Ron Jeffries wrote about the Three C’s of the user story:
- Card – stories are traditionally written on notecards, and these cards can be annotated with extra details
- Conversation – details behind the story come out through conversations with the Product Owner
- Confirmation – acceptance tests confirm the story is finished and working as intended.
In a project following an Agile process, the development team discuss user stories in meetings with the Product Owner. (The Product Owner is the person who represents the customer for the thing you’re developing, and who writes the user stories). First the Product Owner presents the user story, then the conversation begins.
For example: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork.
In this case, questions for the Product Owner might include:
- What information should be collected to allow a user to register?
- Where does this information need to be collected/delivered?
- Can the user pay online as part of the registration process?
- Does the user need to be sent an acknowledgment?
You capture the issues and ideas raised in this Q and A session in the story’s acceptance criteria.
Example acceptance criteria
Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.
So for the above example, the acceptance criteria could include:
- A user cannot submit a form without completing all the mandatory fields.
- Information from the form is stored in the registrations database.
- Protection against spam is working.
- Users can pay by credit card.
- An acknowledgment email is sent to the user after submitting the form.
So as you can see, you write acceptance criteria in simple language, just like the user story. When the development team has finished working on the user story they demonstrate the functionality to the Product Owner. While doing this they show how they have satisfied each one of the criteria.
Get more acceptance criteria examples
For more examples, you can download our user story examples PDF.
The INVEST model for effective acceptance criteria
How do you know if your acceptance criteria set out your requirements effectively? One way is to make sure they follow the INVEST model. You want your user stories to be:
Find out how to use the INVEST criteria for Agile user stories.
Acceptance criteria and the definition of done
People are sometimes unsure of the difference between acceptance criteria and the definition of done. The key difference is that the definition of done applies to all your work, whereas acceptance criteria are specific to individual stories.
Learn more about the difference between the definition of done and acceptance criteria.
Benefits of using acceptance criteria
Including acceptance criteria as part of your user stories has several benefits. They:
- get the team to think through how a feature or piece of functionality will work from the user’s perspective
- remove ambiguity from requirements
- form the tests that will confirm that a feature or piece of functionality is working and complete.
Introduction to user stories — blog series
- Beginner’s guide to user stories
- Adding acceptance criteria to user stories
- User stories and the development process
- Use cases vs user stories
- Bringing stakeholders on board through user stories
- Creating user stories with story mapping
- Improving user stories with a definition of ready
- User story examples
I really recommend this post by Sandy Mamoli. (Sandy is a Wellington Agile coach and scrum master, who we work with on Digital New Zealand). After that, you might like to check out this presentation on effective user stories by Mike Cohn. If you’re working in Scrum, this post shows how to add acceptance criteria when you’re creating user stories in Scrum.
Starting a new project? Check out our Agile Project Kick-off Kit to learn about user story mapping and prioritising user stories during project discovery.