It was a summer afternoon..was thinking on my next post on definition of done..
After a long walk, I was thirsty and went to a fruit juice corner. I ordered a sweet lime juice (my all time favourite). The person standing next to me asked for avocado milkshake.
He took a sip and started shouting on the shop owner…”why you mixed sugar?” “did I ask you?”
“No sir…you did not ask anything other than saying you need avocado milkshake”….politely the shop owner replied.
This shop always stay crowded. They follow a certain set of good practises like only using Bisleri water, wearing cap and gloves , taking care of special instruction like no sugar, no ice etc.
Everyone supported shop owner, stating they followed their usual practise but if customer instruction was incomplete, where is shop owner fault?
I will not continue what happened after this.
Rather this made me to think not only in Agile world, but everywhere silently definition of done and acceptance criteria exist.
Oh now you are thinking, “hmm…till juice story all fine but now what are these…”definition of done”, “acceptance criteria” ..big words..uh”?
Lets handle “definition of done” first
Ah..I forgot to mention..they have some sweet nicknames…definition of done as DOD and Acceptance criteria as AC. Lets try to learn few basics of definition of done(DOD) before moving further.
Why we need to have definition of done(DOD)?
Definition of done promotes transparency in team. Team knows what are the work to be completed for a single product backlog item(PBI) before it is considered as done. So there is no ambiguity in development team mind when they work towards completing a PBI. Definition of Done builds a common understanding towards completeness and quality inside the team. And it promotes transparency within team and stakeholders.
Definition of done lowers the cost of rework once the product backlog item considered as done. DOD prevents a PBI to be promoted to higher environment if it does not meet DOD checklist. Similarly it prevents the PBI to be delivered to customer or product owner or user, until and unless it is checked and passed against DOD, much before sprint review.
Reduces misunderstanding and conflict-
Definition of done acts as an explicit contract between development team and product owner\customer. Hence there is no ambiguity between what customer expects and what development team delivers. If there is any expectation mismatch, development team gets the earliest opportunity to reconcile same with product owner. Without a DOD checklist, it becomes difficult for a product owner to understand the progress on the PBI , hence results in lesser chance of inspection and adaptation in sprint review. A periodic review of DOD checklist in sprint retrospective in the presence of product owner, is a great practise that strengthens the DOD to promote high quality deliverables along with greater customer satisfaction. It reduces last minute conflicts and misunderstanding between team and product owner\customer.
A properly crafted definition of done prevents development team wasting time on non value added work and helps them to focus on the DOD checklist . Having a clear and concise DOD helps development team to know all the work that count for “done” work. Hence they are more focused and they know what are the work needed to be completed and in which order, to ensure product increment meets not only acceptance criteria but also meet DOD checklist. This proper and realistic plan increases sprint velocity and sometimes double it up. Please note if a PBI meets either of AC or DOD, it does not count in sprint velocity. In order to call as “done”, PBI needs to meet both AC and DOD.
Minimises the risk of delay-
A properly defined DOD ensures all and every work that is needed to declare a product backlog item to be completed, are counted and team clearly knows about it. So keeping DOD in mind, development team provides the estimates. Their talk with product owner clarifies the queries upfront and team then starts working on meeting all the items in checklist one by one. As a result, there is no unpleasant surprises at end. A weak DOD on the other hand, tries to hide “needed” work from the DOD checklist which later gets caught while nearing the deadline. As a result, it delays the timeline and lands into a problematic deployment and handover.
Ensures high quality-
Definition of done not only ensures acceptance criteria met but quality is the key focus for definition of done. Definition of done ensures the increment shipped(potentially) is of high quality and the meaning of high quality is well understood by team. It is not considered to be great ending by just meeting acceptance criteria but there is no review of code or some testing skipped etc.
With a weak DOD, development team becomes bit of direction less. At the end of sprint, when team realises too much work left and little time, then they try to cut off some essential quality aspects, like removing some tests, or not adequately completing all test cases or chopping off some functionality etc, in a nutshell poor quality deliverable. On the other hand, following a good DOD, relieves stress from team. It provides an extra layer of protection for development team during tricky bad conversation and saves development team.
How to create a definition of done checklist for your team?
Now that you know fundamentals of definition of done, next question might be “ok..I am fine with all these..but how do we create a DOD checklist for my team”…
Good question..lets see below in a step by step way, how we can create a DOD checklist for our team.
How to use Definition of Done(DOD) in a scrum team?
Now that we know how to create a DOD for your team, the next important question is how to use and maintain it going forward in your team. We can not leave the DOD as it is to accumulates dust. Lets see how we can use DOD in a step by step illustration below.
Example of definition of done:
Common flaws of definition of done:
Over obsession –
Sometimes we tend to be over obsessed with definition of done checklist and we wish to make it an elaborate document. This is counter productive. DOD checklist should be slim and trim , with minimum items involved to assure internal quality. Otherwise people will feel lethargic to use DOD and eventually it will accumulate dust.
Confusion between DOD and Acceptance criteria-
People use DoD and acceptance criteria interchangeably. As a result, team thinks if product backlog item(PBI) meets acceptance criteria , then it is enough , no need to have DOD and not required to check with DOD checklist before considering PBI is done.
But the truth is DOD and Acceptance criteria both are different. While acceptance criteria checks for functionality , DOD looks for functionality + quality. So it is inappropriate to consider a PBI as “done” until and unless it meets both definition of done (DOD) and acceptance criteria.
Craving for shortcuts-
Sometimes development team look for easy way to remove any obstacles that comes on way. One of the way is to weaken DOD to unblock any hindrance. Though it is a quick fix but a weak DOD always bites quality of deliverable and brings more stress during deployment time. We should be mindful that DOD is not just getting approval from PO or customer but it ensures optimum quality of PBI. So lets refrain from weakening DOD to reach a short term goal.
Not showing enough love-
After creation of DOD, people tends to forget about it. There is no further discussion on how to improve DOD or any adaptation needed. It just stays quietly on the confluence team page or team board or Jira .
Please don’t do this. Show some love, some kind gesture to it every now and then , at least rekindle the bonding in sprint retrospective. If we make DOD obsolete by not looking at it, release quality will gradually reduces. DOD loses its effectiveness. Its importance lies being an explicit contract between development team and product owner. Hence DOD should be always evolving and stay upto date to bring best quality deliverables which meets correct functional requirement.
Definition of done is one of the most important concept that we need to understand in Agile. Sometime we just ignore it because of lack of knowledge and awareness of how important role DOD plays in release success.
If you want success, want a stress free deployment, high quality deliverable, defining done matters! People sometime think definition of done only applicable for software development projects but no, it is not correct.
DOD is equally applicable for any kind of project like infrastructure, learning and development, training project etc, just you name it. Only the outlook changes but the main essenceof DOD always remain same and that main essence is striving for quality.
The way a single size does not fit all, similarly a single DOD may not fit all teams. Experts say DOD is a living document and literally it is. Create a definition of done which is very unique for your team, very close to your team and then time to time show love…
And that’s it..you already started walking on the road to meet “Success”!!