Updated: Dec 2, 2020
In any software development process, customer communication with the development team is crucial in creating a well-defined solution. This is done by using product requirements to ensure the team understand the customer’s needs, to reduce ambiguous definitions of requirements and to have an efficient development process.
In the Agile working environment, the communication regarding the functionality required for a specific project is reflected in the form of user stories and well-defined acceptance criteria (AKA: Conditions of Satisfaction).
Acceptance criteria are crucial to the success of the project. They provide a detailed scope of user requirements such as user flow, specific scenarios, product behavior and any other desirable characteristics of the solution. They also reduce misunderstandings and uncertainty regarding the client’s exact expectations.
Acceptance criteria help set expectations between the team and the customer. The use of acceptance criteria guides the whole development process. When they are defined properly, the team use them throughout the different phases of development to understand what is within the scope of a user story. They also help break down the user stories into tasks, provide effort estimations and increase the overall efficiency of development.
Who Is Responsible for Writing Them?
The acceptance criteria serve both the customer and the team. In a happy path scenario, we always prefer that the customer write them (or the Product Owner as a proxy). However, sometimes, they will be written by the development team (especially in cases of technical stories that demand deep knowledge of technical aspects).
Acceptance Criteria Checklist
Although there is no real definition of best practices to use when writing acceptance criteria, I want to share a simple, yet very powerful checklist that I use as a guideline for creating effective acceptance criteria.
Each acceptance criterion should be independent.
Criteria should focus on both the positive and negative flows of the functionality.
If the development team writes the criteria, the Product Owner must ratify them.
They should allow the team to understand the customer’s intent rather than formalize a technical solution.
They should establish the boundary of the user story or feature so the team can easily understand what’s included and excluded from the scope of the story.
They should not include parts of the definition of done such as “code review was done” or “non-critical bug issues”.
They must contain enough details to enable a shared understanding between the customer and the development team. (This is where writing acceptance criteria become an art.).
Each user story or feature should have at least one acceptance criterion written before implementation begins.
They should address both the functional and non-functional aspects of the desired solution.
They should be testable with clearly defined pass/fail results to allow the team to properly confirm that all of the desired intentions have been fulfilled.
A Practical Example of Writing Acceptance Criteria
Let’s see how acceptance criteria actually fit into user stories by using a basic example:
As a student, I want to gain access to the university site, so I can manage my test information.
Acceptance criteria for this example:
The student can gain access to the university site from any device as long as she uses it in the internal university network.
The student can gain access only to her own personal information including test scores, scheduled tests, and average test score.
The student should have the permissions to apply to semester tests.
The student can gain access to the university site from external sites only using the SSH protocol.
The student should have the option to print any information related to her own personal account.