Why is having a Definition of Done not optional?
Suppose you run a bakery. You bake some of the finest cupcakes in town.
A customer walks into your store and says, “I want a cupcake with chocolate flavour, royal icing, cherry on top and in brown wrapping, please”.
You write the details down and send it to the kitchen. Then the chef bakes a cupcake against these requirements.
However, would you serve this cupcake to your customer without satisfying the below criteria?
- Customer confirmed they are not allergic to any of the ingredients
- All ingredients are fresh and edible
- The product/kitchen environment comply with the FSA (Food Standards Agency) rules
- The product baking time within the limits specified in the recipe
- Product shaped properly and no-known defects that could make it inedible or look inedible
The answer here may be seen as obvious. You wouldn’t serve the cupcake to your customer without satisfying these criteria. You must not.
Let’s take “chocolate flavour, royal icing, cherry on top, brown wrapping” as Acceptance Criteria for this cupcake. Another customer may want “white wrapping”. Another one may want “banana flavour, glace icing”. You see where it goes.
Regardless of the Acceptance Criteria that could be varied according to specific needs of the customer, you should have base quality criteria that ensure your cupcake “ready to be served to your customer”. This should apply to all items in your production line.
We call it “Definition of Done” in Scrum. Having a DoD (Definition of Done) helps you have a shared understanding around “what DONE means”. It improves transparency and makes inspection and adaptation relevant.
What could possibly go wrong?
But what could possibly go wrong if you serve your cupcakes to your customers without considering a Definition of Done anyway? What is the risk?
- Customers may be allergic to the some of the ingredients contained
- You may serve stale ingredients that could cause food poisoning
- You may create an inconsistent taste / food experience
- You risk the health of your customers, your reputation, customer retention and you may face legal issues
Probably more. So, everything could possibly go wrong.
What does it look like in Software Development context?
Imagine you work in a company that operates with multiple teams working on one product. The teams do not have a base Definition of Done (or they don’t have the visibility) that ensures product increment is potentially releasable at the Product Owner’s discretion.
“Potentially Releasable” is the term we may want to focus here. Think about it. It's a successful Sprint, the teams satisfied everything forecasted in their Sprint Planning, met the Spring Goal, and completed all features that were perceived to deliver the highest value possible to the customer when released. The product increment has been integrated, functional tests pass, no defect found.
However, you have the items below pending:
- No Performance/Stability tests performed
- Several high severity security vulnerabilities in the code base have not been addressed yet
Now, first remember this excerpt from the Scrum Guide:
The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of "Done".
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
and then ask these questions to yourself:
- Would the Product Owner prefer to wait completion of the above items, before releasing the product increment?
- If she/he decides to release it without validating those items, would it cut the quality and risk your reputation, stakeholder relationship, money, customer retention and overall morale of the company?
- If the teams do not forecast against a DoD that requires “potentially releasable increment” each Sprint, could it have a negative impact on the planning capability of the team, the decision-making of Product Owner and the overall transparency in the organisation?
- Could the teams experience context-switching during the Sprint due to “urgent issues” coming from the work not included in Definition of Done? Such as defects, extra non-functional work found in an environment left out of the Sprint scope?
- Due to the fire drills, could the team members complain about lack of time for attending some Sprint Events, Refinement and even working on the items forecasted during the Sprint Planning?
- Due to the amount of excessive unplanned work, could everything start looking like priority one ?
If your answer is “Yes” for most of the items above, you already have connected the dots on the causal loop diagram and started to think about how crucial it's to make sure you have a Definition of Done that ideally targets crafting a "potentially releasable" increment as the result of each Sprint at latest.
That won’t solve all your problems, but it will help you move in the right direction.
Special thanks to Nithin Bopanna, who is the father of the idea for the cupcake metaphor that we also use during our workshops!