What Is Acceptance Criteria and How to Write It? (With Examples)

What Is Acceptance Criteria?

Acceptance criteria (AC) in agile are the default requirements to be fulfilled by the developers to complete a user story. 

Acceptance criteria are, in other words, a set of points on a check box that teams must tick to mark the scope of a user story. It also involves planning the framework for the tasks. 

The outcomes of the acceptance criteria statements or tasks are either passed or failed.

The above statement means that outcomes may sometimes fulfill the acceptance criteria, and others may not.

These criteria mark the functionality of the requirements. 

Acceptance criteria vary for all the different user stories determining the feature’s functioning from the end-user’s point of view. 

It is also different for various products and user needs. Sometimes acceptance criteria are referred to as the ‘definition of done.’

They get this name because only if you fulfill the acceptance criteria can you consider the user story completed or ‘done.’ 

Writing acceptable criteria aims to reach the highest satisfaction levels among users and stakeholders. Teams can derive the acceptance criteria from the user’s needs and desires and align them with the stakeholder’s expectations. 

Bonus: Want to learn about a framework that prioritizes customers’ needs? Click here to learn about the ‘Jobs to be Done’ framework.

Writing the acceptance criteria in the product backlog lies with the product manager or owner.

Product managers can use product management software like Chisel to write AC in backlogs. 

Try Chisel’s free forever version today!

In agile methodologies, the teams target the user’s needs and expectations.

Therefore, defining the acceptance criteria becomes vital in product development. It helps the developers focus on user success and ensures the delivery of products that the teams are able to align well with users’ requirements.

What Are the Characteristics of Acceptance Criteria?

It Should be Testable With Definite Pass/Fail Outcomes.  

To examine and assess your product, you must have testable acceptance criteria. It is to make sure that you can meet the requirements.

Therefore these requirements shall be testable with a definite pass or fail result. 

The Criteria Should be Straightforward and Compact. 

It is a criterion based on the user’s perspective on which teams shall test the product. Hence, there is no need to make it comprehensive with unnecessary jargon that might lead to the sidelining of the core points of the criteria. 

Also, it’s a set of standards and not a report. Keep it simple, concise, and straightforward. 

Easy to Understand 

The acceptance criteria should be clear and easy for members across the different teams.

Having clear acceptance criteria will avoid confusion and miscommunication and the slowdown that would occur as all the members are not on the same page. 

User Perspective 

User perspective should be the focus of the acceptance criteria. The product can’t be acceptable if it fails to address users’ issues and needs. Teams have to write the acceptance criteria from the actual user’s perspective. 

To make this task easier for teams, you can use a top product management system like Chisel to conduct user research. User Research Pillar by Chisel exclusively focuses on understanding your user perspective.

Purpose of Formatting Acceptance Criteria 

What Are the Examples of Acceptance Criteria?

Example of Acceptance Criteria- 1

This example will focus on the ‘acceptance criteria given when then’ format. It is also known as the scenario-oriented acceptance criteria format. 

As an audience, I must be able to get my password when I forget it. This case is the product acceptance criteria given by a user.

Let’s look at the scenario of the acceptance criteria format. This case includes the forgot password scenario.

Now we will focus on the acceptance criteria given when then:

Given: In this case, the acceptance criteria is that the user logs into their page.

When: After logging in, they will select the option of ‘forgot the password.’

And: Once the user completes the above step, they can enter their valid email address to get a link to reset the password.

Then: The automated system will send a link to the users’ email addresses. 

Given: The user on the other end will receive the link.

When: They can now click on the link, and the system will redirect them to a different page.

Then: The user can now set a new password.

Example of Acceptance Criteria- 2 

In this example, we will look at the acceptance criteria format of rule-oriented.

In the rule-oriented acceptance criteria format, teams mainly consider the bullet points.

As a customer, I want a search option that will allow me to select the cities, street names, and so on to find staying options for paying guests and hotels.

The acceptance criteria format for this one would look something like this:

• The user can find the search option at the page’s top.

• They can start searching once they click on the option ‘search.’
• Users can now see the placeholder with the possibility of ‘where do you want to go?’ written in grey color.

• This particular placeholder will not be visible to the user once they start typing their location.

• The user can see the search results only when successfully typing in the name, city, street name, and more.
• You can perform the search result in the following languages: English, Hindi, French, and German.

• There is a limit to using only 220 words in the search field.
• No special characters are allowed by the search field. 

If users type in any special symbols, they will receive a sidebar pop-up warning: ‘You cannot use special characters to search locations.’

Bonus: Click here to learn about the product requirements document outlining a product’s features and functionalities.

How to Write Acceptance Criteria?

The acceptance criteria vary from project to project, depending on the product and the user story. 

For writing acceptance criteria, you must have comprehensive knowledge of product software development and the project’s task that you will undertake. 

The primary frameworks or acceptance criteria formats that you must follow are-

Given/When/Then Acceptance Criteria is a scenario-oriented criteria format. The format here is – “Scenario: (description of the scenario). Given (what all are the given conditions), when (a particular action taken), then (the result of that action).

Let’s look at the acceptance criteria example: an online food ordering app. The acceptance criteria for the app would include:

• Specific features include locating the user, displaying the nearby available restaurants, and estimated delivery times.

• The restaurant’s menu.
• Options for sorting and filtering based on the user’s choice and likeness.

So, in the above case, the user story would look like this- Given a user’s location, when they go through the restaurants’ apps, they find a list of restaurants with menus displayed and the estimated time for delivery. 

In the case of the scenario-oriented format, teams don’t address the design, user experience limitations, and other details. You can include these details in the rule-oriented acceptance criteria. 

You must follow the rules in this acceptance criteria format to define the software system’s behavior. It forms the constraints for drawing up scenarios. These rules are for the testing of the functionality of the product.

Success Criteria vs Acceptance Criteria

Success and acceptance criteria are essential terms used in project management and product development. While they are related, they have distinct differences.

Success criteria are the high-level goals or objectives a project or product aims to achieve. They are typically defined at the outset of a project and guide the project team toward achieving the desired outcome. Success criteria are often expressed in terms of business value or benefits, such as increased revenue or customer satisfaction.

On the other hand, acceptance criteria are the specific, measurable conditions that a product or service must meet to be accepted by the customer or user.

They determine whether the product has met the desired quality standards and requirements. Acceptance criteria are typically defined in collaboration with the customer or user and are often expressed in terms of functionality, performance, or other technical specifications.

Here are some key differences between success criteria and acceptance criteria:

1. Scope: Success criteria focus on the overall goals and objectives of the project, while acceptance criteria focus on specific product or service features.
2. Level of detail: Success criteria are often stated at a high level, while acceptance criteria are more detailed and specific.
3. Perspective: Success criteria are typically defined from the perspective of the business or project team, while acceptance criteria are determined from the perspective of the customer or user.
4. Timing: Success criteria are typically defined at the outset of the project, while acceptance criteria are described during the development process in collaboration with the customer or user.
5. Outcome: Success criteria are used to measure the project’s overall success. In contrast, acceptance criteria ensure that the product or service meets the desired quality standards and requirements.