Opponents of agile often complain about the lack of planning, specification and design. This is rather a misunderstanding since most agile terms denote a form of planning, specification and design. Acceptance criteria is a great example to prove this: it is a good basis for planning the verification process, specifying solution requirements and elaborating the design.
What is Acceptance Criteria?
Acceptance criteria are predefined requirements that a solution must meet. The development process targets to meet the acceptance criteria. The verification procedure relies on it to determine the suitability of the solution.
Acceptance Criteria and the Definition of Done
These terms are not interchangeable, even though both concepts set conditions and requirements a solution must meet. But they do so from a very different perspective:
- Acceptance criteria describe requirements toward a backlog item, something specific the solution must meet.
- Definition of Done regulates the process of delivering a solution, something generic that all increments must meet.
Ideally the definition of done states that a backlog item is done if – among other conditions – it passes the acceptance criteria.
More about the definition of done >>>.
Acceptance Criteria and User Story
Technically, acceptance criteria do not need to be part of a user story. First, requirements or backlog items are not always user stories. Second, a given set of acceptance criteria can match multiple user stories. What is more, even epics and features can have acceptance criteria. In the end, it depends on team practices.
We should rather say that acceptance criteria and user story complement each other. The user story defines a business requirement, that is to say, tells the business goal and business reason. The acceptance criteria, on the other hand, details the solution via the expected behavior of a system.
More about user story >>>.
Characteristics of good acceptance criteria
Since it is part of the requirement specification, it should be clear for all team members, leaving little room for personal interpretation. It provides guidance to developing and testing the solution.
Since it is used for solution verification, acceptance criteria should be testable. Developers and testers can only rely on the acceptance criteria if it makes a clear distinction between fail and pass cases. Therefore, acceptance criteria may refer to measurements, quantifiable attributes, binary states. Whenever possible, acceptance criteria should avoid claiming that a solution must be e.g. good, warm, big. Rather, it should state something like error-free, 60 degrees celsius, 1920x800px.
Since accepting the solution depends on the acceptance criteria, it should cover all perspectives of the solution. This can mean interacting with a system from the aspect of users having different roles, it can mean security and performance requirements, but even a very specific action.
Positive and negative scenarios are both subject to acceptance. For instance, it is typical to check if users without proper entitlements can perform actions. Dialogue forms often validate certain data formats and values.
Even though acceptance criteria must be more specific than the base user story, it still should avoid over-specification. Good acceptance criteria leaves room for creativity and engineering, that is to say, it lets the developers elaborate the best possible solution which implements the goal of the user story.
Perhaps needless to mention: since it is part of the specification, should be defined prior to development.
Who and when should write the acceptance criteria?
One of the distinctive characteristics of agile software development is the iterative, incremental approach. Instead of specifying everything upfront, the product backlog is just a collection of ideas and the backlog items evolve over time. Decoupling different parts of the requirement specification to user story (potentially written by the product owner upfront) and to acceptance criteria (potentially written by the team just before sprint planning) is a convenient way of solving this problem.
As a thumb rule, agile methodologies do not assign the task of writing acceptance criteria to any particular role. Rather, the product owner and members of the delivery team should come to a conclusion together regarding when they accept a solution (see the 3C’s – conversation). This process is an efficient way to discover different aspects of a requirement and to address its potential shortcomings (see the 3 Amigos). For this reason, acceptance criteria is a form of requirements specification, often as a part of a user story.
Formulating Acceptance Criteria
There are several popular techniques for writing acceptance criteria, however, there is no single solution that fits all situations. The 3 major approaches are:
- Given – When – Then;
- Checklists;
- Custom or free formats.
Given – When – Then (Scenario-Oriented)
Probably the most popular technique is the Given – When – Then scenario template. This format was first introduced by Business Driven Development (see Dan North: Introducing BDD). It is often called ‘gherkin’ which is the name of this syntax in Cucumber. It suits interactive systems very well. The logic of this template is the following:
Given that a condition is true (e.g. a system is in a given state – actually any number of condition could be included),
when a specified event occurs (e.g. the user takes an action),
then a specified outcome is desired (e.g. the system should respond with something).
Let’s see an example:
Given that I am logged in to the system,
when I click on my avatar,
then the system should display my user account page.
Checklist (Rule-Oriented)
This given-when-then approach is not always useful. Let’s suppose our user story is about exporting a data table into a file once a day, even if the table is empty. Instead of struggling with the conditions defined in the template, we are more interested in defining the list of criteria the export files should meet. For instance
- file type,
- number and order of records,
- number and order of columns,
- data types,
- encoding, etc.
Thus, what we really need is a checklist. Even though we could mix the checklist with the given – when – then scenarios and we could have a list of scenarios, too, that would come with lots of waffles, making it difficult to quickly read and capture the requirements.
Custom or Free Formats
Life can be complicated and the systems modelling it, too. Even seemingly simple things can become suddenly too complex to handle. A good example is when a series of third-party solutions deliver significant value embedded in our user story. Let’s suppose a web development relies on a framework which manages responsive design. We do not even know how the underlying solution will exactly behave, thus setting very specific criteria beforehand makes little sense. In the end, someone inevitably must check the outcome in detail and decide whether tuning is necessary.
Benefits of using acceptance criteria
Using acceptance criteria is one good way of defining how to verify a solution. Since the agile delivery process uses small, ideally independent user stories, test scenarios and test cases should follow suit.
Writing acceptance criteria as part of backlog refinement is a good technique for facilitating discussion on backlog items, scrutinizing the requirements from various perspectives, involving the entire team in the process to gain a strong, common understanding of business goals.
Decoupling the business and solution parts of the requirements definition process helps to make the delivery process agile. The product owner can capture business goals anytime while the team can set the acceptance criteria in the last responsible moment, before starting the development.
Acceptance criteria can describe functional and non-functional requirements. User stories rarely address the solution since they are for specifying business goals. Therefore, non-functional requirements are often neglected. Writing acceptance criteria is a good occasion to cover non-functional aspects of a solution.