Bernd
October 23, 2020
In this article I will take a closer look at the subject of Acceptance Criteria (AC). In Scrum, AC are usually part of every Product Backlog Item (PBI) in the Sprint Backlog and make it easier to assess whether a PBI is 'done'. If you look for a definition of AC in the Scrum Guide, you will notice that AC is not mentioned anywhere. This reminds us of the term 'Definition of Ready', which we have already looked at in a previous blog post.
Ideally, AC define the clear and complete conditions that a PBI has to meet in order to be implemented, tested and completed by the Scrum team. These conditions can relate to functionality or even design-specific attributes, they are different for each PBI and are usually limited to a number in the single-digit range. Good AC ensure that the entire development team has the necessary understanding to complete a PBI.
Conditions that must be met by all PBI are defined in the DoD, unlike AC. Usually these conditions are pre-defined guidelines or standards which are generally valid for all PBI. In our DoD there are requirements such as "The code adheres to our common style guide" or "A minimum of 85% or higher code coverage is achieved" as well as "All acceptance criteria of the user story or ticket are fulfilled".
As mentioned before, precisely defined AC make it easier for the development team to work on a PBI. Without carefully defined criteria, which functions and properties a PBI must have, it will be difficult or impossible to complete the PBI. For this reason, techniques such as test driven development are often used, in which AC are formulated as automated tests that the development team guides during implementation.
There is no fixed rule as to who creates the AC for a PBI. Often AC are defined by the Product Owner (PO) when creating a PBI and then adapted and extended in the Backlog Refinement. It is only important that all persons involved in the planning communicate sufficiently and that all changes are transparent. When a PBI is taken over into a Sprint, it must be guaranteed that it contains AC that meet the requirements of the Scrum team. A PBI without an AC should not be adopted in a Sprint.
Often a PBI contains a checklist of requirements, which are listed under the heading Acceptance Criteria. This applies in particular to requirements that cannot be expressed as automated tests, such as requirements for UI/UX. There is, however, no predefined format for AC, and each team must learn to create them as is best for their situation and circumstances.
Furthermore, AC should not be defined too generally, but on the other hand not too specifically. This can otherwise lead to AC that are hardly possible to fulfil or that restrict the implementation unnecessarily. An effective AC depends on the requirements of the PBI and should be measurable and testable.
If requirements are defined as source code via automated tests, tools such as Spock are often used, which use a given/when/then format
- Given some precondition
- When some action is done
- Then the result is as expected
This approach, of using automated tests, can also help when reviewing the changes, so other team members can validate that the requirements are met.
I hope that these observations have served to make the term "Acceptance Criteria" somewhat clearer. Sometimes the distinction between "Acceptance Criteria" and "Definition of Done" is not made very clear.
In the end AC are an important item on any PBI and should not be overlooked by any team that wishes to improve performance and cut down on PBI that do not meet the requirements of the PO or manager.
In our everyday work we make sure that each PBI defines a list of AC and that automated tests in the source code are provided, so that the path to 'done' is as smooth as possible. Of course, transparent and regular communication within the team remains indispensable.
Working as a software engineer for many years mostly in the JVM environment. Skilled in Scrum and Agile practices, currently scrum master of nerd.vision.
