When writing a user story for development team, the acceptance criteria are the oft overlooked part that can make the difference between whether what is built does what is needed, or not.
We’ve all seen vague user stories that say something like:
As a patient:
I want an appointments screen
So that I can make an appointment
That might be enough information to get some sort of functionality but not necessarily something that works the way that your customers need it to, or that handles all the ways that this screen might be used.
What you need are some acceptance criteria for this story…
What are acceptance Criteria?
The acceptance criteria are the criteria agreed by the team and the product owner that will be used when the story is complete to agree that it can be signed off.
Why do we need them?
A good set of acceptance criteria makes it super clear to everyone on the team what this story covers, anything not included in the acceptance criteria doesn’t need building.
Having a clear scope of exactly what is in the story makes estimating the story simpler, if that is something you do, and makes writing test cases simpler as well.
A story without clear acceptance criteria can devolve into a more complicated piece of work, with important scenarios being missed, and superfluous features being included.
What makes a good one?
A good set of acceptance criteria describes the situation that we are addressing for the user, and the results that we expect from different actions. These are written as a number of scenarios, each with an unambiguous action and outcome.
How do we use them?
Each scenario should be discussed with the development team (and stakeholders if necessary) prior to the team starting work on the story. If the team aren’t clear on each scenario and what it is trying to achieve then update it with them until there is a shared understanding of what needs building.
When it comes to reviewing the completed story each of the scenarios in the acceptance criteria is used to sign the story off.
If the resulting work doesn’t address all of the acceptance criteria then don’t sign it off.
If the complete story is missing something that was not in the acceptance criteria then the acceptance criteria is what is wrong, not the development
Show me how to write one
There are loads of different ways you could write these, my favourite is to use the Gherkin style from behaviour driven development. Written as Given, When, Then.
The format goes something like this:
Scenario name:
Given the initial state
When an action occurs
Then a thing will happen
Here’s an example from a user story, “As a patient I want to book a doctors appointment online so that I don’t have to wait on hold on the phone”
Scenario: Logged in user views appointments
Given that I am signed in to the surgery website
When I choose to make an appointment
Then I will see a list of available appointments in the next 48hrs
Scenario: Non logged in user views appointments
Given that I am not signed in to the surgery website
When I choose to make an appointment
Then I will be shown options to login or register
Scenario: User Selects an available appointment
Given that there is an appointment available
When I select a specific date and time for an appointment
Then I will be asked to confirm the booking
etc.
Notice that these acceptance criteria do not talk about what the button looks like or what it says on the button or how the appointments are presented. This is not a UI design spec. These are about the journey that the user may go down to get their job done, and the scenarios that they may encounter on the way.
That’s not to say that you couldn’t write every list detail of what happens when you click on a dropdown or submit a form, but you’d end up with way too many scenarios, even for a very simple story.
In more advance development organisations your testers or developers may use these gherkin tests to form the basis of automated testing, but even if that’s not something your team does this way of documenting behaviour remains powerful and unambiguous.
There are more complex rules that you can add into your gherkin to capture more complex scenarios, but this basic set get you a lot way towards clear unambiguous acceptance criteria.
Read more about Gherkin here: http://docs.behat.org/en/v2.5/guides/1.gherkin.html