Acceptance criteria are essential to Agile frameworks. They are at the center of any discussion about the work that needs to be done. However, as important as they are, little time is being dedicated to them in most Agile trainings. Here, I will try to remedy the situation by shedding light on this element that is at the heart of the Product Owner’s life.
What are acceptance criteria?
If the user story is the element that allows us to discuss a need, acceptance criteria are the result of this discussion. They serve two objectives :
- Remind everyone what defines the need that we want to answer;
- Show the validations needed to ensure that the business need is filled.
The Product Owner is responsible to make sure that any work ready to be started is described in terms of acceptance criteria. It’s actually thanks to them and the discussion they represent that teams can estimate the effort required to satisfy the need described.
When and by whom are the acceptance criteria written?
There are several good answers to this question that have the following traits in common :
- The team is engaged in the discussion about acceptance criteria;
- The knowledge about the business domain is transmitted to the team.
Here are a few examples of situations frequently encountered:
- The acceptance criteria are created during the refinement of the product backlog (grooming). During those exercises, the Product Owner and the team exchange the keyboard in order to document the conversation in the form of acceptance criteria.
- The team that masters the business domain asks the Product Owner to make a first draft of the acceptance criteria to optimize efficiency during the refinement exercises.
- The team that is part of the discussion about the high level needs (discovery session) lets the Product Owner make the first draft with the acceptance criteria.
- In a multiteam context for a product, individuals coming from diverse teams are participating to the elaboration of the acceptance criteria.
What we are looking to avoid is that the Product Owner or the analyst writes “his” acceptance criteria and presents them to the team without having a discussion, especially if the team does not master the business domain.
Do the acceptance criteria describe the business requirement or the solution?
The acceptance criteria reflect the behavior of the user and give details about his need.
A good starting point is the default scenario, the one that has no exception or error. Thus, a user story to enable a user to create an account could have as an acceptance criteria :
- Considering that the < user > does not already have an account in the system, validate that he can create one with his name and email address.
- Validate that the user receives a confirmation that his account has been created.
Then come the exception scenarios. What happens if an account is already associated with this email? Or if the user provides erroneous information? For each exception, the team can choose between processing it by adding new acceptance criteria or creating new user stories.
Regarding the solution aspect, especially the interface and user experience elements, the team should be able to do this job on its own. As much as possible, we need to avoid having steps of graphic creation and user experience upstream of the development in order to not create professional silos.
Certain acceptance criteria can also document non-functional prerequisites such as performance or conformity to certain standards.
What is the best format to write the acceptance criteria?
The acceptance criteria can take different forms. They can be written like small user stories, or take the form of examples to facilitate automating the acceptance tests (specifications by example) or even simply be a list of things to verify. All these forms are valid if :
- Each acceptance criteria can clearly be defined as “met or not met”.
- Each acceptance criteria is testable.
- Each acceptance criteria adds value to the product.
What are acceptance tests?
The acceptance tests are used to validate that the acceptance criteria are met. These tests are often done by hand. However, with the emergence of development methods oriented on the need, like BDD and ATDD, these tests are coded.
The most important is to not believe that acceptance criteria are light versions of use cases or test scenarios. These can be laborious to write and hard to understand well while acceptance criteria aim at being simple, clear and collaborative. The key words are : collaboration, need and validation.