When you’re creating, building, or developing a product – whether it’s software, a marketing campaign, or something else – how do you know that what you’ve made fulfills your customer’s expectations? Enter, acceptance criteria: the conditions required for the customer, product owner, or stakeholder(s) to accept the work you’ve done.
These criteria are not inherent to the scrum framework, but many scrum and agile teams use them to organize work and deliver results that delight.
Acceptance criteria are defined as the conditions that must be satisfied for a product, user story, or increment of work to be accepted. While not a part of the Scrum Guide, AC can be a useful tool teams may choose to use to improve the quality of product backlog items.
Also shortened to the acronym AC, these conditions are pass/fail. Acceptance criteria are either met or not met; they're never only partially fulfilled.
AC are often expressed as a set of statements. These statements should be:
Acceptance criteria do not focus on “how” a solution is reached or “how” something is made. Instead, they illuminate the “what” of the work you are doing. For example, the criteria may be:
Users can pay with Google Pay or Apple Pay at checkout.
The spirit of acceptance criteria is not to tell you how to do it, for example:
Install a Wordpress plugin that allows you to create a checkout page.
Write HTML that makes it possible to pay with Apple Pay or Google Pay.
These statements get at how the work will be done, not the conditions for accepting the work. It’s up to the developers on the scrum team to decide the how of fulfilling the acceptance criteria.
The agile practice of formally stated acceptance criteria started in software development, but today they are applied to a wide array of deliverables in addition to software products across diverse industries, from app development to Human Resource departments and beyond.
For some scrum teams, a user story is the smallest chunk of work and one way to express a product backlog item. Your team may use something other than user stories to define and describe PBIs. Many teams simply leave their PBIs as PBIs.
Acceptance criteria are not the same thing as a user story. Instead, they complement one another.
A user story is a brief description of your customer's needs, written from their perspective. It describes their goal or problem they’re trying to solve. The acceptance criteria are what should be done to solve their problem or achieve their goal.
In this way, the user story describes the “why” of the work, while the acceptance criteria describe the “what.” The “how” is decided by developers as they work through the sprint.
What does your customer want, expect, or need from the product you are making? An answer to this question will help us identify the acceptance criteria. After all, our goal is to delight the customer.
Because we all work in unique industries and jobs, acceptance criteria don’t always originate from a traditional customer. Instead, it may be your product owner’s or stakeholders’ criteria or those of another type of client or user.
Some of the opportunities for defining acceptance criteria include:
On a scrum team, the product owner is often responsible for writing these conditions of acceptance; however, the development team can and should be involved to offer their expertise and feedback while aligning with the product owner’s expectations.
The scrum master on the team can support the process by looking for potential ambiguities with the criteria, helping the team understand the purpose of AC, and encouraging developers to speak up if the criteria are unclear.
In these ways, it truly can be a team effort, even though the product owner’s proximity to the customer is often the starting point for generating the criteria.
In scrum, we continuously talk about product backlog items as part of planning and refinement activities. Initial criteria are often identified during backlog refinement; however, finalizing the acceptance criteria should be done right before development begins.
Just-in-time acceptance criteria ensure you’re working with the latest information, including the customer’s goals and expectations. A good time to finalize the criteria is during the sprint planning event. The scrum team reviews the statements, discusses any issues or clarification needs, and decides whether the work can be brought into the sprint.
Templated approaches to writing the criteria can be found across the internet. When it comes to the Scrum Guide, there is no guidance because these criteria are separate from the lightweight framework of scrum. Try different formats – either custom or from a template – and see what works well for your team.
Many teams simply use a bullet list. You can easily generate the list and place it in the user story or wherever else you’re organizing the work in your sprint.
Whether you use a bullet list, a table, a numbered list, a short description, or a sticky note, a custom approach can be a great option. Consider including your acceptance criteria format as the topic of a retro so you can inspect and adapt its effectiveness for your team.
Other agile teams will use a format known as scenario-based, in which you use a formula: Given that; when; then:
For a checkout page on a store’s website:
For an upcoming conference:
Given that I’m a registered attendee
When I enter the conference venue
Then branded signs will lead me to the registration table
For an emailed water bill statement:
For a health clinic’s pre-appointment paperwork:
Given that I’m an existing health center patient,
When I schedule an appointment online,
Then I will receive the fillable pre-appointment paperwork electronically
When applying agile practices in the real world, you should feel empowered to experiment and see what works. But generally, you can see below why writing AC in certain ways is ineffective:
This criterion will probably go over fine with your development team and is unlikely to cause any immediate issues; however, it technically tells the development team “how” to make it possible to remove items on the checkout page: by including a checkbox.
As an online shopper, I want to be able to remove items from my shopping cart on the checkout page so that I can easily make last-minute adjustments without clicking the back button.
Explanation: The criterion technically goes beyond the scope of the user story. This can lead to too much work being lumped into one user story.
As it goes with all things agile and scrum, there’s always some gray area between “good” and “bad” ways of writing acceptance criteria. The tool is yours to experiment with. Something that one team considers “bad” may work well for another team and its customers.
Use your retrospective to inspect how the acceptance criteria are working with the approach you're using. Adapt as necessary.
While there are many ways to customize acceptance criteria to your team and your context, there are also common pitfalls that tend to run counter to the purpose of AC:
Most agilists find that they can get the most benefit from acceptance criteria by writing them clearly while focusing on user experience and customer expectations.
You may be wondering how these conditions of satisfaction are different from the definition of done (DoD). After all, the work of the product backlog item is done once the criteria are met, right?
While it’s true that both DoD and acceptance criteria indicate a done state, they aren’t quite the same.
The definition of done is typically expressed as a list of statements that must be met in order to call the work potentially shippable or to otherwise declare that work complete. The big difference is that the same DoD applies to every product backlog item and does not change between items.
The acceptance criteria are different for each product backlog item.
Here is an example of DoD:
Here’s another one:
Sometimes a team will call something “done” when referring to the acceptance criteria. If the terminology causes confusion, you may want to consider calling the work “accepted” instead of “done” when referring to the acceptance criteria.
Acceptance criteria benefit agile teams and scrum teams because the criteria:
Try using them with your team if you aren’t already. You may find that acceptance criteria improve communication and collaboration, and connect you more closely with what your customer needs.
If you work on a scrum or agile team and you’re interested in gaining the knowledge, credibility, and skill of an experienced scrum team member, please explore our certifications.
As a Certified Scrum Product Owner, you can make sure your customers receive products that delight in part by helping the people who build the product understand what the client wants and needs. As a Certified ScrumMaster, you’ll coach your team to greatness by supporting their growth and understanding of scrum principles, values, and practices - including acceptance criteria.
Get the latest resources from Scrum Alliance delivered straight to your inboxSubscribe