Table of contents:-
- What is an Acceptance Criteria?
- What are the characteristics of acceptance criteria?
- Purpose of formatting acceptance criteria
- Writing the acceptance criteria
What is an Acceptance Criteria?
Acceptance criteria in Agile is the set of default requirements that are to be fulfilled by the developers to complete a user story. Acceptance criteria is in other words a set of points on a check box that must be ticked 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 fail that means either the acceptance criteria is met or not, which marks the functionality of the requirements.
Acceptance criteria varies for all the different user stories determining the feature’s functioning from the end-user’s point of view. It is also different for different products and user needs. Sometimes acceptance criteria is referred to as the ‘definition of done’ because only if the acceptance criteria are fulfilled can you consider the user story to be completed or ‘done’.
The point of writing acceptable criteria is to reach the highest levels of satisfaction of users and stakeholders. The criteria are derived from the user’s needs and desires and are aligned with the stakeholder’s expectations. The responsibility of writing the acceptance criteria in the product backlog lies with the product manager or owner.
In Agile methodologies, the teams target the user’s needs and expectations, therefore defining the criteria of acceptance becomes vital in the product development as it helps the developers to focus on user success and ensures the delivery of products that are well aligned with user’s requirements.
What are the characteristics of acceptance criteria?
Should be testable with definite pass/fail outcomes
To examine and assess your product you need to have testable criteria. It is to make sure that the requirements are met, and 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 the product shall be tested so 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 criteria and not a report, keep it simple, concise, and straightforward.
Easy to understand
The acceptance criteria should have clarity and must be easy to understand for members across the different teams to avoid confusion and miscommunication and the slowdown that would take place 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 the user’s issues and needs. The criteria have to be written from the perspective of the real user.
Purpose of formatting acceptance criteria
- Quality assurance is one of the prime targets of writing the acceptance criteria.
- AC is used to set boundaries and define the scope of the project. The acceptance criteria determines the functionality of the product.
- To ensure that all the cross-functional teams and team members are on the same page and there lies no ambiguity in the project processes.
- Reaching agreement between team and clients regarding the product’s functionality and completion of development.
- To mark out the negative scenarios of a user story. Negative scenarios could be like, unauthorised access, unexpected behaviour, wrong password etc. The AC you format can decide how the product or the system shall react to it.
- It focuses on communication by linking the client’s perspective with the product development cycle. To develop a shared understanding of functional behaviour of the product features among the developers and communicate that with clients and stakeholders and align with their expectations and desires.
- AC helps to create a structure for the user story and supports planning for the project by fragmenting it into separate tasks. This helps in strategizing and effort assessment.
- The acceptance criteria forms up the base of the user story acceptance testing. The acceptance testing is done to get a straightforward answer to the question, whether the product’s version shall be acceptable or not.
Writing the acceptance criteria
Depending on the product and the user story, the acceptance criteria vary from project to project. For writing acceptance criteria it is required to have comprehensive knowledge of software development and the project’s task that is being pursued.
The basic frameworks or formats for writing acceptance criteria are-
- Given/When/Then Acceptance Criteria- It is a scenario oriented criteria format. The format here is – “Scenario: (description of the scenario). Given (what all are the given conditions), when (a certain action taken), then (the result of that action).
- For example- An app for online food ordering. The acceptance criteria for the app would include certain features such as locating the user, displaying the nearby available restaurants along with estimated delivery times, restaurant’s menu, and options for sorting and filtering based on the user’s choice and likeness.
- So in this case the user story would look like this- Given a user’s location, when they go through the apps for restaurants, then they find a list of restaurants with menus displayed and the estimated time for delivery.
- Rule-oriented acceptance criteria- It is useful for user stories of system level functionality. In case of the scenario oriented format the design, user experience limitations and other details are not addressed. These are included in rule oriented acceptance criteria.
- In this format, rules are laid out to define the behavior of the software system. It forms the constraints for drawing up scenarios. These rules are set up for the testing of the functionality of the product.
Q: How many acceptance criteria should a user story have?
A: There must be at least one criteria that the software should fulfill in order to be acceptable. There can be many acceptance criteria depending on the type of software and user story. Having a good number of acceptance criteria leads to product refinement and user success.
Q: Who should write the acceptance criteria?
A: The product owner or stakeholder usually writes the acceptance criteria. It is required from the person who writes the acceptance criteria to have a good understanding of software development, and the user requirements and behavior.