Have you ever thought, ‘Now that’s done, what is next?’ only to find out that it actually wasn’t quite done? You had to go back and change things.
If only you had known about those last-minute things ahead of time. Your work could have been so much more efficient and effective. But instead, not just one, but two projects are delayed!
Or have you ever thought, ‘I’m nearly done but I’m not sure if I should do A, B, or C. I think it has to be C’, only to find out later that it was actually A, or worse, something completely different—D.
Or maybe you’ve thought, ‘Hey, this looks cool, let’s do it!’ Three days later, having done it, you showed it to others, who also loved it.
But what about all the extra work you just generated, let alone the fact that no one would use it if it was not documented. We’ve simply forgotten in our excitement that it still needs to be demonstrated, supported, maintained, tested, and and and… I personally love this one, as you’ll see later.
There’s an old saying in Stephen Covey’s book, The 7 Habits of Highly Effective People: ‘begin with the end in mind.’ This does not mean that we know the end in great detail, but rather that we have a vision in our head of what the result will look like.
We should have a vision not only of what the result will look like, but also what it will not look like. Things we should not have.
I recently came across this beautiful quote by the French writer Antoine de Saint-Exupery: ‘Perfection is not when you cannot add more, but rather when you cannot take more away.’ Think of the iPod, iPad, and iPhone—the removal of a keyboard made those devices simpler to use. Not only simpler to use, but also to manufacture.
So, why bother acceptance criteria?
I hope we now see why!
Focus Focus Focus
We need to have an idea of what we want to achieve before we start. This will make sure that those producing the work focus on what is needed now and nothing more. If new ideas do come into mind, then write them down. Record them. Don’t lose them—but don’t just do them!
Yes, of course it takes a little time. It takes a little investment to think about and record each acceptance criterion. But surely this is time well spent in the long run.
So when should we write acceptance criteria? Ideally before the implementation work begins!
In the Scrum world this could be during Sprint planning, but it is better done during backlog refinement or “grooming”. In Kanban, surely we simply set up a policy for a phase/stage, indicating that the story is only ready when the team has discussed and recorded the acceptance criteria.
In DSDM the acceptance criteria should be completed in foundations for the upcoming increment.
Who should write the criteria? Everyone should be able to. But clearly the ownership is with the product owner (Scrum) or business analyst (DSDM).
What are acceptance criteria? Let’s start with what they are not. They are not technical tests. They are not, for example, boundary tests. These should be covered by unit tests that the developer needs to write.
These, for example, are not acceptance criteria:
- Try to enter the date June 31, 2015.
- Try to enter 11 characters even though the maximum length is 10 characters.
- Try to enter a carriage return in a single line field.
In more traditional language, the above examples are ‘white box tests’ and acceptance criteria are known as ‘black box tests’.
Importantly, acceptance criteria are tests that are written from an end user’s perspective.
Acceptance criteria can look a lot like this:
- Try to pay with a valid MasterCard – SUCCESS
- Try to pay with a valid AMEX card – FAIL (we don’t accept AMEX)
- Try to go to the home page by clicking on the logo – SUCCESS
- Try to click <BACK> on the browser after paying – FAIL
- Try to click <BACK> after logging in – you should still be logged in
Ah, but what about that old gem, technical stories?
The end-of-day job must still run at a particular time, and be completed within a particular time period—even when triggered by another process and not a human being. They still need them, damn!
What else are acceptance criteria useful for? They are the test cases that the testers should be preparing and writing, especially for test automation.
If your environment is truly advanced, not only can this be done in parallel to the implementation, but doesn’t this appear to fit the notion of Test Driven Development (TDD)? More specifically, why not write the tests before the code so that you know the code works.
Oh It is Too Complex
Acceptance criteria are also useful as indicators of complexity. When there are too many acceptance criteria, perhaps the ‘simple’ story should be broken down into smaller parts. Otherwise we are clearly trying to deliver something too big.
Don’t do it because it is Cool
Finally, the next time you developers think it would be cool to be able to drag a tab from a table in a browser to create a new instance of the browser with just that table, please think again. Though it might be cool to implement, how many people will actually use it? Who has actually asked for it? Who will test it, maintain it, document it, etc? You? Probably not… and just perhaps that is where we need to focus. Not on you.
Think beyond you. Above was a real case and a real waste of time, effort, and ultimately money. If we had written acceptance criteria for that project, it is unlikely that would have been done.
Acceptance criteria will save not only you time and money but also your colleague’s.
They increase focus and motivation throughout delivery. They eliminate waste, by the bucket.
They are a direct line to delighting not just you, but the whole team as well as the end-user, your customer.
And You? Have a Think About These Questions (Book 15 minutes if you want to discuss)
- Do you discuss Acceptance Criteria with your team?
- So you do discuss them, but do you record them too?
- Where are your test cases coming from – from one person’s head or the entire teams?
- Is the team focused on delivering exactly what is needed, or are they delayed because they did not know?
Want to discuss? Contact us…