Everything You Need to Know About Acceptance Criteria

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 Defined

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:

• Clear, so that everyone understands them
• Concise, so that there’s no ambiguity
• Testable or verifiable 
• Focused on providing customer-delighting results

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.

Or -

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.

Acceptance Criteria vs. User Stories: What’s the Difference?

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.

Who Should Write the Acceptance Criteria?

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. 

A Process You Can Use to Create Acceptance Criteria

Some of the opportunities for defining acceptance criteria include:

• Discussions with customers or clients
• Discussions with stakeholders
• During product backlog refinement
• During the scrum sprint planning event
• In team brainstorming
• After evaluating customer or end-user feedback

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.

When Should You Write Acceptance 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.

How to Write Acceptance Criteria

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.

Use a bullet list, checklist, or verification list.

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.

Use the scenario-based template.

Other agile teams will use a format known as scenario-based, in which you use a formula: Given that; when; then:

• Given (some given context or precondition), when (I take this action), then this will be the result

A Checklist for Writing Acceptance Criteria

• Clear to everyone involved
• Can be tested or verified 
• Either passes or fails (cannot be 50% completed, for example)
• Focus on the outcome, not how the outcome is achieved
• As specific as possible (fast page load speed vs. 3-second page load speed)

What Are Some Examples of Acceptance Criteria?

For a checkout page on a store’s website:

• PayPal, Google Pay, Apple Pay, and all major credit cards can be used to complete the transaction
• Shopping cart item(s) are displayed
• Items can be deleted from the shopping cart
• User is prompted to log in if they aren’t already

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:

• Displays amount due
• Displays due date
• Displays possible late fee
• Allows user to log in and pay easily 
• Lets user know how they can contact the office with questions or concerns

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

Examples of Bad Acceptance Criteria

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:

Example 1

Acceptance criteria:

• The online shopping cart uses checkboxes to select which items you want to delete

Explanation:

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. 

Example 2

User story:

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.

Acceptance criteria:

• The online shopping cart allows users to remove items when they’re on the checkout page, and when you view an item detail page, you can see a “Quick Shop” option

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.

Key Takeaway

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.

Common Mistakes to Avoid When Writing Acceptance Criteria

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:

• Ignoring the user perspective
• Telling the developers “how” to do the work
• Writing acceptance criteria too early
• Waiting until development is underway in the sprint to write the acceptance criteria
• The criteria are broad
• The criteria are vague
• There are a cumbersome number of criteria (a large quantity may indicate you need to break up the work into smaller parts)

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.

Acceptance Criteria vs. Definition of Done

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:

• Code is completed

• Tested

• No defects

• Live on production

Here’s another one:

• Brand compliant

• Peer reviewed

• Stakeholders have been informed

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.

The Value of Acceptance Criteria to Agile Organizations

Acceptance criteria benefit agile teams and scrum teams because the criteria:

• Create a clear line of understanding from end user to product owner to developers
• Let the developers know exactly what they need to accomplish during the sprint
• Can be created quickly and concisely, supporting the value of working software over comprehensive documentation (while also supplying documentation if it is needed for compliance in your industry)
• Create clarity and reduces ambiguity so that a self-managing development team can do their work efficiently 
• Reduce the odds that your customer will feel their expectations were unfulfilled
• Provide criteria for testing the product

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.

Support the Team With Clear Acceptance Criteria

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.