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

Max 8min read
Acceptance Criteria

What Is Acceptance Criteria?

Definition of Acceptance Criteria

“The acceptance criteria feature means the predefined requirements that developers must meet to declare the completion of a user story. The product owners must create unambiguous 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. 

Efficiently manage your product backlog and build a roadmap using the four pillars of chisel’s roadmap sections: treeview, kanban, release, and timeline.
Efficiently manage your product backlog and build a roadmap using the four pillars of chisel’s roadmap sections: treeview, kanban, release, and timeline.

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 

  • Quality assurance is one of the prime targets of writing the acceptance criteria.
  • You can use the acceptance criteria to set boundaries and define the project’s scope. The acceptance criteria determine the functionality of the product.
  • The other reason to have the acceptance criteria format is to ensure that all the cross functional teams and other members are on the same page. Also, it helps to know that there is no ambiguity in the project processes.
  • The acceptance criteria format helps to reach an agreement between the team and clients regarding the product’s functionality and completion of development.
  • To mark out the pessimistic scenarios of a user story. Negative scenarios include unauthorized access, unexpected behavior, wrong password, and more. The AC or the acceptance criteria format can decide how the product or system will react.
  • It focuses on communication by linking the client’s perspective with the product development cycle. To develop an understanding of the functional behavior of the product features among the developers. Also, communicate with clients and stakeholders and align with their expectations and desires. 
  • Having the criteria for acceptance helps create a structure for the user story and supports planning for the project by fragmenting it into separate tasks. This segregation of tasks helps in strategizing and effort assessment.
  • The acceptance criteria form the base of the user story acceptance testing. Teams can conduct the acceptance criteria testing to get a straightforward answer to whether they shall accept the product’s version.
Benefits of Acceptance Criteria
4 Benefits Of 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. 

Rule-oriented acceptance criteria- It is helpful for user stories of system-level functionality.

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.


How many acceptance criteria should a user story have?

There must be at least one criteria that the software should fulfill to be acceptable. There can be many acceptance criteria depending on the type of software and user story.

However, having many acceptance criteria leads to product refinement and user success.

How detailed should acceptance criteria be?

Teams must use the acceptance criteria format to mention requirements in a clear and layman language.

While writing acceptance criteria, another point to keep in mind is to make two things clear: acceptable and unacceptable outcomes.

The acceptance criteria feature must also be testable. It should be easy for the developers to translate acceptance criteria into test cases.

Who should write the acceptance criteria?

The product owner or stakeholder usually writes acceptance criteria. It is a must that the person who writes the acceptance criteria has a good understanding of software development, user requirements, and behavior.

Various product management tools can assist the product owner in writing the acceptance criteria effectively.

Crafting great product requires great tools. Try Chisel today, it's free forever.