Acceptance criteria are a range of conditions that a given product must satisfy before the end-user, consumer, or group of stakeholders accepts it. These set of statements specify whether a project passes or fails the functionalities and requirements set forth by users. In simple terms, they represent if a customer is satisfied with certain criteria or not.
These criteria reinforce the work that a team is doing by defining measurable margins of user stories. It helps both parties determine when a project is completed and working properly.
In order for acceptance criteria to work, they must be easy to understand for both teams and users. They need to be clear and concise, and easily rendered within different tests. It is important to note that acceptance criteria shouldn’t be a copy of requirement documents. They are two separate things. The criteria should aim to define the limits of a user story while helping the entire team understand the needs of the stakeholders or product owners.
When Should they be Written?
It is common practice to write the acceptance criteria while the user story is being discussed, as this usually helps a team with estimation. However, they can also be jotted down when the story gets picked.
Acceptance criteria will often give life to a lot of conversations from developers, especially when the story hits their meeting room. Generally, the problems and thoughts brought up during these conversations are added to the acceptance criteria.
There is no specific time when these criteria must be written, just as long as they are established before developers began to work on the project.
When developers are done working on a user story, they must show the final product to the product owner, and prove how each criterion is met. These forces a team to focus on how features work from customer’s perspective, and it also limits the developers from adding a number of unnecessary functionalities to a project.
The 3 Aspects of Good Acceptance Criteria
Functional and Non-Functional Requirement
There are different types of requirements that identify specific user tasks, functions and requests. These can be broken down in functional and non-functional
requirements. A functional requirement refers to a technical aspect of a project. For example, “If a user clicks on ‘Send Message’ Outlook will pop up.” A non-functional requirement deals with non-practical aspects such the colour of buttons and windows inside an app.
Good acceptance criteria separate these two functionalities, and then properly categorize them.
Expected performance is normally measured as a response time. Fore example, 1-3 seconds to query a response. This should always be stated as a goal, and not a solved solution. For example, “A user can generate an audit form” as appose to, “A user can click submit to generate an audit form.” The criteria should not state how the solution would be implemented, as it limits the options and creativity of developers.
A good Acceptance Criteria clearly defines the acceptable parameters of outstanding open defects. They answer all questions in regards to how and when they should be addressed, as well as how they should be prioritized.
Example of Acceptance Criteria
Let’s say that the customer of an online shopping catalogue wants to implement advance search options on the front page, so that his users can quickly and easily refine their search.
The acceptance criteria should be written in a simple to understand language that the customer can decipher, similar to the user story. It can include something like:
- Limit the search by format and type.
- Delineate the search by a date range.
- Limit the search to publisher info like author, title, subject, publisher, and place.
- Restrict the search to specific collections and brands.
- Filter search by availability
When the developers are done with the user story, they can use each criterion to show how each feature has been satisfied.