Acceptance Criteria: What, why and how?Oct 2nd 2015

Building a website is a complicated process. I don’t want to downplay the importance of technical expertise, but for me the most difficult part of a website build is clearly and concisely capturing a client’s requirements. So much hinges on the hours we spend discussing business processes, sketching out UML diagrams and cataloguing every detail. However so often a lot of effort goes in and the resulting documents aren’t as clear as we would have hoped.

the most difficult part of a website build is clearly and concisely capturing a client’s requirements

So how do we improve on this situation? Acceptance criteria. To the uninitiated acceptance criteria are a bit like requirements. They seem to just state a single requirement for a change or fix. The difference is that requirements come in all shapes and sizes, acceptance criteria all look the same. In fact they even have a clearly defined format to help keep to a standard. They look like this:

“Given that… When... Then…”

You should read this as “Given that some precondition is satisfied, when an action or actions take place, then a testable result will occur”. This format lets you turn requirements in to unambiguous, testable, acceptance criteria, which helps developers know exactly what to build, testers know exactly what to test and most importantly helps the actual development go as smoothly as possible.

For example, a typical requirement might be:

we want single sign on between the website and our invoicing system

This could translate in to any number of acceptance criteria so it is important to be unambiguous about what is meant.

Given that I am a user in both the invoicing system and the website, when I visit the website and I am already logged in to the invoicing system, then I am automatically logged in to the website on the first page load

This is much clearer about what is needed. It is still not especially detailed, but it better highlights the additional information which is required, meaning it will be easier to write further acceptance criteria for that as well.

We like to introduce clients to acceptance criteria early on in the requirement gathering stage to let them know what we’re aiming for. It helps guide discussions when you are all internally trying to boil down requirements to these simple little maxims. We still go through all the same processes to uncover the requirements in the first place, the workshops, the diagrams and flowcharts, but then before we start development we review all of that documentation and produce a functional specification including all the acceptance criteria.

This process really ties the requirement gathering phase and development phase together. You can be the best business analyst in the world and have a lot of great techniques for discussing your clients requirements, but unless you can translate them into manageable, testable chunks it’s very tricky to know if you’re delivering what was asked for. That’s why for me this will always be the most important part of a project.

Written by: Rob Humphries, Project Manager

Microserve is a Drupal Agency based in Bristol, UK. We specialise in Drupal Development, Drupal Site Audits and Health Checks, and Drupal Support and Maintenance. Contact us for for further information.