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.
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.
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.
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 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.
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.’
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.
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.
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.
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.