Acceptance criteria in Agile

Documentation in general in Agile

In the world of Agile, there is a manifesto, the Agile manifesto, created in 2001 by Agile pioneers. The Agile manifesto contains 4 values and 12 principles and even though it was written with software development in mind, it can be adapted for using Agile in which ever environment you are working. The core values and principles are the same if you are doing software development, building hardware or working as a manager.

One of the 4 core values in Agile is that we value “Working software over comprehensive documentation”, a statement that does not say that we should not do any documentation, only that we value working software/hardware/systems more than writing documentation about them.

With the core value for documentation in mind, let us look deeper in to one type of documentation that we have in every single project, the requirements.

Requirements change

In Agile, we accept that requirements change with time and that it is at the end of the project we know, and understand, the requirements the best. Unfortunately, at the end of the project is also when it is the most difficult, and expensive, to make changes. Having this knowledge makes it obvious that it is not efficient to document every requirement in the beginning of the project and change them as we know better, and even worse would be to stick with the original requirements to the end. Being unprepared for changing requirements will cause us to deliver something that does not give the customer the value they want.

Preparing for changing requirements in Agile is done by breaking down work into smaller pieces the closer they are to being worked on and by formulating the requirements as acceptance criteria on the different breakdown levels.

Acceptance criteria – The WHAT

Acceptance criteria are the Product Owners breakdown of what to achieved in order to deliver the value the customer requests and therefore it is the Product Owner who is responsible for the them. Being responsible for the acceptance criteria is not the same as knowing them all, the Product Owner can use the team and other resources in order to clarify them, but the responsibility to do so is clear.

There are two goals for acceptance criteria:

1. To describe WHAT we want to achieve – Only what to achieve in order to deliver the requested value to the customer is relevant. The how, tasks we have to do in order to fulfill the acceptance criteria is up to the team to decide at a later time.
2. To remind us what we need to have a conversation about – Acceptance criteria are written with the best knowledge we had at that time. When we look at them again, we will know more and they might change. That is a turn of events that we expect and when it happens, we will talk about it and change the acceptance criteria.

An acceptance criteria should be written on the form of a question that only can be answered Yes or No so that it is perfectly clear to everyone when it is fulfilled. An acceptance criteria should never contain “AND” or “OR” statements, as that could cause a situation where part of an acceptance criteria is done and part is not.

Breaking down work with acceptance criteria

The principle breaking down work into greater detail the closer we get to actually start delivering the value is true for all Agile, but the names and methods for the different levels can be different depending on which frameworks is used. In SAFe (scaledagileframework.com) for instance, the breakdown levels are Epics, Capabilities, Features and User Stories, all the way down to Tasks. In this article, I will focus on SAFe and start at the feature level, as features and the levels below are the what the teams work with on a daily basis.

Acceptance criteria for Features

In SAFe, features are pieces of value that can be completed within one Program Increment (in approx. 8 weeks) and are either created as a result from breaking down Epics and Capability or are generated on their own from a need that is small enough to fit within a feature.

A feature has a business statement that clearly states the value it will bring to the customer (internal or external) and the acceptance criteria we formulate for the feature are the goals we have to achieve in order to deliver that value. It is also in the acceptance criteria for the feature that we include any Non-functional requirements (NFRs) to ensure that we will take care of them.

Next step is to break down the feature into User Stories, where every User Story MUST be created with the goal to fulfill, or help to fulfill, AT LEAST ONE acceptance criteria. At least one is an important rule to stress that there is not a one-to-one relationship between acceptance criteria and User Stories, one User Story could address one or multiple acceptance criteria, and multiple User Stories can be necessary to fulfill one acceptance criteria.

Acceptance criteria for User Stories

As stated above, User Stories that are connected to features are created to fulfill at least one of the features acceptance criteria. If it seems necessary to create a User Story for a feature that is not connected to any of the features acceptance criteria, there is an acceptance criteria missing from the feature.

Acceptance criteria for a User Story describes what we have to achieve in order to complete the user story and are on a more detailed level than the acceptance criteria for the feature.

Tasks – The HOW

The last breakdown level is Tasks, also known as the Team Breakdown because it is the team that is responsible for breaking down a user story into tasks. The big difference between acceptance criteria and tasks is that the tasks describes HOW to complete the acceptance criteria, and thereby the user story. That is also the reason why it is the team responsibility to create them, as the team members are the ones who knows the best way to fulfill the acceptance criteria.

The same rules apply to tasks as to acceptance criteria, each task has to be there on order to address an acceptance criteria but there is not a one-to-one relationship between acceptance criteria and tasks. A task can cover many acceptance criteria and multiple tasks could be necessary in order to fulfill one acceptance criteria.

Example

A very simplistic example of a feature that is easy to understand. It’s just an example and not complete in any way.

Feature: “A vehicle to transport food around the city”

Acceptance criteria

• Is the vehicle safe for the driver?
• Is the vehicle environmental friendly?
• Is there space for food in the vehicle?
• Is the food kept hot during delivery?
• Is the driver protected from the weather?
• …

Breakdown into User stories

• As a food delivery employee, I want a vehicle to transport food so that I can make deliveries in the city.
  • Acceptance criteria
    • Does the driver have the necessary protection to use the vehicle safely?
    • Can the vehicle transport food for 3 deliveries?
    • …
  • Tasks
    • Buy a bicycle
    • Buy a helmet
    • By a backpack for food.

• As a food delivery employee, I want a vehicle that travels faster than 50 km/h so that I can deliver food faster.
  • Acceptance criteria
    • Is the top speed of the vehicle greater than 50km/h?
    • Is the vehicle classified as environmentally friendly by the city?
    • …
  • Tasks
    • Buy an electric engine and convert the cycle into a motorcycle.
    • Buy a motorcycle helmet.
    • Buy protective gear.
    • Send the driver to motorcycle school to get a license.
    • Buy and install a box to the back of the motorcycle.

• As a food delivery employee, I want to be protected from the wet and cold so that I can deliver food even when it is bad weather outside.
  • Acceptance criteria
    • Is the driver protected from rain?
    • Can the driver keep warm when it is below 0°C outside?
    • Is the food kept warm when it is cold outside?
    • …
  • Tasks
    • Buy an electric car.
    • Install a heated box in the trunk of the car.

The example also shows that we can start do deliver value from the first user story, even though all of the acceptance criteria in the feature is not completed.