Acceptance criteria

The difference between Definition of Done and Acceptance Criteria?

In a previous article, I spoke of Definition of Done or DoD which focused on the criteria which must be met to consider a project completed.  Definition of Done is used at a ‘global’ level meaning. For example, if the DoD criteria is set at a user story level, it applies to all stories.  This process enables a common understanding across the team of quality and completeness.

Find a more detailed explanation of the difference between Acceptance Criteria and the Definition of Done in this Project Management Glossary episode:

Each user story (or requirement in traditional projects) will be somewhat unique and should, if done correctly, reflect the users’ perspective and need.  In order to create metrics to assess how that need can be considered as met, there need to be criteria agreed upon between the user and the project team.  These criteria are then used to confirm user acceptance of the deliverable once done.  These are the Acceptance Criteria and they will be individually set for each story.

Acceptance criteria are particularly useful for test cases that can complete quality assurance based on that criteria and assure acceptance by the user, Product, or Business owner.

Why do projects need Acceptance Criteria?

It is important that a project is clear on the distinction between Acceptance Criteria and the Definition of Done and to use both to the best effect.  Quality and completeness are two key attributes that need to be measured in order to define value and the point at which value can be realized.  

To start with though, let’s focus on one of the biggest killers of all projects...vague stakeholders.

Even if you can draw out the requirement or user story, it is highly unlikely it will be water-tight enough to hold up to multiple perspectives and subjective interpretations.  Typically a requirement or story will require some level of analysis just to ensure it is understood.  Even when done with a requirement owner, story persona, or end-user directly there is no guarantee that what comes out of the development pipe will match what was envisaged.

There will be numerous constraints to development that can legitimately cause this but not all of them are easily understood by those outside the development team.  A basic constraint could be developer experience and capability as well as how good understanding they have of an end user’s context - what will their code be used for? how will it be used, how often? and so on.

Analysis of these points will assist the developer to produce a higher likelihood it will meet the need. However, that does not necessarily mean it will be accepted once done.  This can ultimately result in costly rework and excessive iterations of the developed work and ultimately the dreaded scope creep. Other reasons why projects need acceptance criteria can include:

• Refining non-functional requirements - these create clear guidance for a project team on how the software or infrastructure must behave in specific scenarios or under certain conditions including when the unexpected happens (a negative scenario).
• Flow through to quality assurance and testing - acceptance criteria can be used to create consistency and traceability through discovery and analysis of the requirements, through development, and all the way to final testing prior to a release.

Establishing this consistency through the lifecycle anchors the project team and the users or requirement owners to a common understanding and assists the project to meet deadlines.  In the test phase, the assessment of the developer that they have met the acceptance criteria in the finished product can be independently verified as a key assurance process prior to a release.

How to write acceptance criteria in your project

A developer should assess the data points which establish context with a user, through the requirements or story analysis phase in an iteration.  In traditional projects, this is usually done by a business analyst in a requirements definition document and can have a hierarchical format such as:

• 1. Heading,
• 1.1 Requirement,
• 1.1.1 Acceptance Criteria 1,
• 1.1.2 Acceptance Criteria 2,
• and so on.

This is a relatively simple process of working through each scenario in almost an interview format with the user and documenting each point.  It is important that this is not an excessively exhaustive process (you can't reduce the risk to anything so don't try) and that the acceptance criteria are realistic and attainable.

Agile projects will follow a similar approach however can be simpler given the user story establishes some user context and desired outcomes already.

The Agile process can follow Epic > Story > Acceptance Criteria as the hierarchy and must be done before the development team has commenced work.  It sounds like an obvious point but you would be surprised how big a gap this is in most projects.

Take any project with quality assurance or user acceptance issues and they are all likely to have deficiencies in their acceptance criteria or worse, do not have them at all.  An idea to help embed this in your pre-development process is to implement a step where acceptance criteria are required prior to estimation.

Each project can approach defining acceptance criteria slightly differently.  If your project is at least focused enough to try to document acceptance criteria then you are on the right track.  However, like any project process, there are different ways to best complete this task and some will work better than others depending on the type of project or product being developed.

There are different approaches at a high level that a project can use to guide the development of acceptance criteria. Here are two examples:

1. Given-When-Then formula (scenario-based)

The Given-When-Then formula was developed by Dan North as part of his Behaviour Driven Development process.  It allows the development team, testers, and users to create and manage a common understanding of how an application should behave when interacted with.

Take the User Story of “As a customer of the eShopping site, I want to add a product to my shopping cart so I can purchase it”.  One scenario that might be explored for acceptance criteria can be “Adding to Shopping Cart” (note that there are multiple scenarios in this user story).

The scenario will be based on the user story and will give the acceptance criteria an easily identifiable label that will be understood by the end-user and the development team (as well as testers).

The Given-When-Then formula gives your team a format to work through and define acceptance criteria:

• Given - establishes the context or preconditions that should exist prior to action e.g. "Given I have navigated to the page of the product I wish to select it to proceed to purchase on the eShopping site".  This part of the formula can also establish data or system preconditions that must be present at the beginning of the action.
• When - the action was taken by a user and the input data that might need to be entered (this also can be then action that is replicated during a test) e.g. "When I click ‘add to cart’…"
• Then - the outcome expected when performing the action which will include the output data and the postcondition (end state) e.g. "Then I will see a counter appear on the shopping cart icon at the top right of my page (with the sum of all products I have added to cart in that session)"

The GWT formula can be used repeatedly to break down the user story into all the possible scenarios that should be tested and validated that a user's requirements will be met.  It also has the added benefit of allowing for the application behavior to be independently tested and can improve quality prior and reduce developer rework prior to a release.

2. Checklist or rule-based

On occasion, the GWT formula won’t work or is simply not fit for purpose for some acceptance criteria.  Instead, a simple set of rules must exist when observing the application behavior.  This can be a bullet list or checklist of rules that can be validated as the developer completes their work.

Using our same User Story “As a customer of the eShopping site, I want to add a product to my shopping cart so I can purchase it”, the developer can create the list of rules which a user agrees with and draw out multiple scenarios:

• Clicking on the product image takes me to the product page
• The ‘add to cart’ button is displayed on the right of the product image and information
• The ‘add to cart’ button is always visible as I scroll down the product information page
• When I click the ‘add to cart’ button it adds a counter to the shopping cart icon
• The shopping cart icon is displayed permanently at the top right of my page
• The shopping cart counter will cumulatively add every additional product I select until I check out
• And so on...

Final words on the acceptance criteria

Acceptance Criteria can take many different forms and there are tried and tested methods available but ultimately it is up to you how you want to apply them.  The key is to create a common language and understanding between your users, developers, and testers.  Doing this will achieve greater results, reduce the risk of increased costs and rework as well as drive greater advocacy and early adoption of the changes being released.

Check your projects and if you have not got acceptance criteria, put processes in place before your next sprint to ensure they are there. You’ll be pretty amazed at the difference it makes when you have them.

The Acceptance Criteria FAQs