This post is part of the Pride & Paradev series.
“Understanding is the knowing of misunderstanding”
~ Zivarnna Smithies
As the team’s paradev I am responsible for writing acceptance criteria against each user story to specify what constitutes completion. This is done after discussion with our product owner and subject matter experts.
I personally dislike the somewhat popular Gherkin (Given/When/Then) format for acceptance criteria – as I find it distracting from declaring intent, and also find it a gross waste of the limited business stakeholder attention I have trying to coerce things into this awkward format (see more discussion in my previous The Color of Acceptance is Gray post).
For our project: acceptance criteria are a series of checkboxes against a user story card in Trello. These are marked as complete by the programmer and when all checkboxes are ticked then the story is ready for test.
So, should acceptance criteria be implicit or explicit?
Acceptance criteria should be implicit
All things in life are implicit. When my wife asks ‘can you go to the shop and get me some milk’, she doesn’t also have to tell me ‘and don’t buy anything else in the store’, ‘and make sure it’s 2 liters of 2% fat pasteurized non-homogenized cow milk’, ‘make sure it’s refrigerated’ and ‘pay with cash and use our Flybuys card’. These are implied criteria from our shared understanding.
Acceptance criteria are the same. If I had to explicitly state every acceptance criterion for every story; I would never cease from writing acceptance criteria.
Recently I have, reluctantly, started including acceptance criteria that really should be implied: ‘page has page title’, ‘page passes WAVE accessibility’ etc. But where do you draw the line? Next I’ll be writing “works in a web browser”, and “works on the Internet”.
Keep acceptance criteria focused on what is required, not what is obvious.
Acceptance criteria should be explicit
“It pays to be obvious, especially if you have a reputation for subtlety.”
~ Isaac Asimov
“The obvious is that which is never seen until someone expresses it simply.”
~ Kahlil Gibran
If you don’t have explicit acceptance criteria then it can be very hard to determine whether what has been developed is actually completed.
The more effort you put into writing clear, explicit acceptance criteria is well rewarded by receiving a story that has all required functionality included in it. This means less rework because each time you find an acceptance criterion induced bug it means the programmer has to context-switch to fix it which is less time spent working on a new story.
Conducting a user story initiation with the programmer before development, and a developer-tester dev-box walk-through as soon as development is finished is a great way to ensure that the acceptance criteria you have written is explicit, and has been implemented exactly as intended.
Even though some things are obvious requirements (eg ‘page passes WAVE accessibility’), these are often forgotten so it pays to have a standard list of common acceptance criteria and include them on every user story.