Acceptance Criteria and their Role in Setting up Quality | David Tzemach
Updated: Mar 3, 2022
Customer communication with the development team is crucial in creating a well-defined solution in any software development process. This is done by using product requirements to ensure the team understands the customer’s needs, reduce ambiguous definitions of requirements, and have an efficient development process.
In the Agile working environment, the communication regarding the functionality required for a specific project is reflected in 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 solution characteristics. 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 appropriately defined, the group uses 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 actual definition of best practices when writing acceptance criteria, I want to share a simple yet 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 story's scope.
They should not include parts of the definition, 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 correctly confirm that all of the desired intentions have been fulfilled.
A Practical Example of Writing Acceptance Criteria
Let’s see how acceptance criteria fit into user stories by using a basic example:
Story:
As a student, I want to gain access to the university site to manage my test information.
Acceptance criteria for this example:
The student can access 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 personal information, including test scores, scheduled tests, and average test scores.
The student should have permission to apply to semester tests.
The student can access the university site from external sites only using the SSH protocol.
The student should have the option to print any information related to her account.