Other factors alike, a good and useful done criteria differentiates a good user story from a great one. In this post, let’s talk about some ways to make “done criteria”, that works.
What is Done Criteria?
Done Criteria or Definition of Done are the metrics used to determine, if the User Story is considered complete and acceptable for End User delivery.
It serves as a checklist for Product Owner and the Testing Team to ensure the completeness of implementation. It also provides the basis for agreement between Production Definition and Development Teams.
But many times they are overlooked…
It happens because there are “assumptions”.
Assumptions have the potential to kill a project. They aren’t inherently bad, but really really bad when they aren’t explicitly stated.
When the End User provide requirements, they assume something.
When someone writes a User Story, the assumption multiplies.
When the development team understands the Story, the assumptions skyrocket exponentially.
I am sure you must have come across the famous How Project Really Work cartoon.
A good done criteria strives to minimize the damage.
Follow the rule of EAT
Here is a simple technique to evaluate the quality of done criteria.
1. E for Explicit
By this, the story creator must make sure to put everything down in the done criteria. It may be silly, stupid or a “well known” fact. Doesn’t matter. Put things down in the done criteria. It can be removed later if not agreed by everyone else.
Let’s take an example. What do you think about this definition of done?
User must be able to delete an existing order
Sounds pretty okay, right!
What if me, the user, assumes that I will have a means to “undo” my action and get the order back. What if I assume that deletion is not applicable to orders created 6 months back?
It is always better to state additional details than missing the important ones.
2. A for Assertive
Sometimes the done criteria is written in a non-assertive ambiguous tone. This is a recipe for disaster.
By assertive, I am referring to putting things in “black and white”. If some condition is not met and it is critical, then the story fails acceptance.
Make your language so clear that anyone can understand what is critical for acceptance and what is not.
3. T for Templates
It is quite common that some criteria are standard across stories for acceptance.
A good example is the pass percentage of Test Cases. Together with your team and management, agree not to accept a story if the pass percentage is less than a specific value.
It is a reasonable idea to make such criteria as part of the standard done criteria or definition of done. These are the basics for any story to be accepted and taken to next level.
- Done Criteria or Definition of Done is essential for a great user story
- A good one reduces rework and greatly increases the chance of acceptance by Product Owners and End Users
- Follow the rule of EAT – Be Explicit, Use Assertive Language, Make Templates for standard criteria
- Remember not to ignore the importance of “good” Definition of Done. Otherwise, you might regret it later
How do you evaluate the worthiness of done criteria in your user stories? I would love to hear them.