What are acceptance criteria?

With every product or solution, it’s important to take a broad look at the user experience. Every interaction a customer has with a product or solution tells a story, from the moment they first discover it to when they have completed its use (hopefully with the desired result!).

Acceptance criteria are the predefined requirements that have to be met to mark a user story complete. Product managers and product owners should be familiar with acceptance criteria. People in these roles may be responsible for writing acceptance criteria for the stories in product backlogs.

The payoff of well-defined and articulated acceptance criteria is more satisfied users and stakeholders, as well as product teams that are more closely aligned.

Acceptance criteria are the conditions required for the product, user, or stakeholder to accept the work that has been done. They define the scope and requirements of user stories. This gives developers the context they need to create a satisfying user experience by making sure that each feature does what it promises to do.

Many agile and scrum teams use acceptance criteria in their projects, although they’re not inherent to the scrum framework.

Acceptance criteria serve several purposes:

• Clarifying the user story by outlining the expected outcome in a way that helps developers execute the vision

• Giving other people on the project, such as members of the QA team, definable goals and action points they can refer to in determining if a user story is complete

• Ensuring that everyone is on the same page and working toward the same overall goal

• Removing subjectiveness from the project, promoting alignment and proper teamwork

• Preventing scope creep, a phenomenon that occurs when a project’s requirements go beyond what was set out in the original plans

User stories and acceptance criteria are similar important aspects of a project, but they serve slightly different purposes.

The user story is a high-level overview of how a product or solution functions from a user’s perspective. It focuses on what and why. It’s also more flexible, allowing for alteration and adjustment as a product is continuously evaluated and developed.

Acceptance criteria, on the other hand, are the set of accepted conditions or rules that the product or solution must meet to satisfy functionality requirements. They are an important part of the overall user story, adding a layer of specificity that provides everyone with a common understanding of when a story will be complete.

In product development, the definition of done (DoD) is a checklist that every user story needs to meet for the product team to consider the piece of work acceptable and complete. It’s a universal standard that can be applied to every user story related to a specific project. The DoD includes quality control items such as resolving any documented bugs and completing any applicable unit tests.

In contrast, acceptance criteria are specific to each user story. They help establish testing criteria and clarify the expected outcome of that particular user story.

Both DoD and acceptance criteria are beneficial in their own right, and you can use them in parallel.

There’s no single method for formatting acceptance criteria. Your project’s scope, the target audience, and your team’s specific skill set should all play a role in determining acceptance criteria formatting.

In general, there are three acceptance criteria formats:

1. Scenario-oriented acceptance criteria formatting

2. Rule-oriented acceptance criteria formatting

3. Custom formatting

Scenario-oriented acceptance criteria (Gherkin acceptance criteria)

Scenario-oriented acceptance criteria formatting tends to be the most popular format. It uses Gherkin, a domain-specific language developed for writing acceptance criteria. It helps users define when to start and stop testing a particular feature.

This format tends to reduce the time you spend writing test cases as it uses a given/when/then (G/W/T) structure that mirrors test case writing.

Rule-oriented acceptance criteria

If you can’t fit acceptance criteria into the Gherkin format, consider rule-oriented acceptance criteria formatting. This style details the behavior of a system, allowing you to draw specific patterns based on that behavior.

A benefit to this format is that it often allows you to use simple bullet points to outline scenarios and outcomes.

Other acceptance criteria formats

Having acceptance criteria in place is far more important than micromanaging the formatting. You can choose either of the popular formatting styles or create a custom style. You can also involve your team, asking them what style they prefer and what they understand best. Some teams prefer using plain text for acceptance criteria.

You might need to experiment with using a few different formats to learn what works best for your team.

While anyone on a product or cross-functional team can write acceptance criteria, the product manager is typically best-suited to write it. They are usually tasked with understanding the granular details of customer needs and can bring those needs into the discussion using strong critical thinking skills.

Having one person in charge of facilitating the development of acceptance criteria is helpful, but multiple team members should be involved in the final version. Important points can be added to the criteria when developers, QA engineers, and other team members bring different perspectives.

Some teams opt for a collaborative approach to writing acceptance criteria, with everyone on the team contributing something to the final product. If you opt for this approach, ensure that everyone understands the expected outcome.

Good acceptance criteria help your team stay on track and execute project tasks more effectively. They can also lead to improved customer satisfaction, as the end result is taken into account before work even begins.

Take writing acceptance criteria seriously and use the tips below as a set of guidelines. The better the acceptance criteria, the better the whole team will understand and deliver on the story.

Identify the user story

The user story should be top of mind at every step of your project. Constantly think about things from the customer’s point of view. Reference the user story frequently—not only as you write the acceptance criteria but as you progress throughout the project.

Define the ideal outcome

Think about what success looks like for you and the project. Specifics can help here. Thinking about the desired outcome can help give you and your team goals to aim for. Whether the ideal outcome is improved app usability or more conversions on a client website, defining the ideal outcome can help everyone on the team work toward a common goal.

Create acceptable scenarios

Along with the ideal outcome and user story, you should think specifically about how users will interact with your product or solution.

Highlight your requirements

Your team members need to know what requirements to achieve before the desired outcome can be reached. Include all contributing factors in the acceptance criteria, including technical specifications, functional requirements, design points, and other details.

Prioritize clarity

Everyone on your team should be able to understand the acceptance criteria. If anything seems confusing to you, it will likely be confusing to others.

Avoid the temptation to write acceptance criteria using overly technical jargon. Keep things simple and clear whenever possible.

Don’t forget to review the criteria regularly

Acceptance criteria can change as your project progresses. It’s not often realistic to commit to one set of acceptance criteria and expect them to remain unchanged over the subsequent weeks. Revisit and review your acceptance criteria regularly to ensure they are still relevant.

Get feedback from all team members

Seek feedback from other members of your team to avoid overlooking anything or missing important details. After all, one of the greatest benefits of acceptance criteria is keeping all team members on the same page. It can be an excellent team-building exercise to review acceptance criteria, allowing for any questions to be answered as a group, giving everyone a voice, and incorporating suggestions.

There are many ways to write good acceptance criteria, but clarity is the most important thing to keep in mind. Use simple language that focuses on the user and how their needs will be met. Involving your team in the process is also important.

Acceptance criteria focus on the what of the work being done, not the how. Here are a few examples of well-written acceptance criteria:

• “Users can sign up to receive personalized emails at checkout.”

• “Users receive notification emails after a successful registration.”

• “Users will be registered automatically for future emails.”

Acceptance criteria enable you to clarify the scope of the work and demonstrate exactly how you plan to satisfy your customers. It’s up to the developers on your team to outline how the tasks will be accomplished.

Traditionally, acceptance criteria are written before or during backlog grooming sessions. The criteria can then be brought to meetings for discussion with other stakeholders. Therefore, you can choose to refine acceptance criteria even as the product or solution’s user story is being built out.

Note that acceptance criteria should be defined before the active development phase begins. This will enable you to reap the benefits of acceptance criteria, including team alignment and definable goals.

There are two popular types of acceptance criteria formatting: scenario-oriented acceptance criteria and rules-oriented acceptance criteria.

Scenario-oriented acceptance criteria define a precondition or situation, while rules-oriented acceptance criteria are employed when scenario-oriented acceptance doesn’t fit the project or desired outcome.

Acceptance criteria are not mandatory. Even so, they can be instrumental to a project’s success or failure.

Acceptance criteria enable a team to demonstrate to stakeholders that they have kept the user story in mind while developing a product or working on a project. They can also keep the team more aligned and improve customer satisfaction.

Behavior-driven development (BDD) is a way to write acceptance criteria that gives examples of how software should behave in different scenarios.

This type of acceptance criteria is written in a standard given/when/then format that is both simple and streamlined, allowing for easy integration.