How to Deliver Quality Software Faster with Definition of Done?
Do you have any idea as to what is the biggest impediment in a Software Development & Delivery Process? It is ASSUMPTIONS!
If you want to know more about it, please read one of my blogs here. where I’ve tried to help you with listing out the impediments and assumptions.
Having said that ‘Assumptions’ are the major impediment to software development and delivery, it is vital to kill all the implicit and invalid assumptions if you want to:
• increase transparency
• speed up the delivery process, and
• ensure maximum quality
And here’s the secret recipe: Using Definition of Done (DoD) is the best way to kill your assumptions!
I’ve observed that many people consider it as an additional effort when it comes to defining an effort or a task as complete. But trust me, having a well-defined understanding of completion will have a huge impact on when and how you deliver your project.
What is your DoD? This is one such question you often hear in Agile software development. Well, let me tell you, Definition of Done is a must-have not only in agile but also in any processes. Shall we move on to discuss more on what it is and why it is important?
What is DoD and Why is it so Important?
According to leadingagile.com, “The definition of done (DoD) is when all conditions, or acceptance criteria, that a software product must satisfy are met and ready to be accepted by a user, customer, team, or consuming system.”
Before moving onto DoD pertaining to software development, let us understand the meaning of it in a simple context.
Consider you went to a coffee shop and ordered a coffee. You were really tired and were in need of that coffee to rejuvenate yourself from stress. You spent time there eagerly expecting a coffee of your taste and preference ie. with less sugar, more beans, a little cream and you ‘assumed’ that you would get it.
How do you feel when you get it not as per your expectations? While ordering coffee, you should have told them you need it with less sugar, add more coffee beans with a little cream on top of it. This is your definition of done, which has the power to kill the assumption of the coffee maker. Now he will be able to give you that perfect coffee you needed.
DoD in a Software Development Environment
The above coffee shop example is very much relevant in a software development setting as well. People tend to go with assumptions which will make things worse and leave our efforts in vain. Here’s an example from software development itself.
Raj was assigned to do some testing by Anoop for a particular project and he was working hard to finish it on time. On the next day’s standup, Raj claimed that he completed testing and the issues had been logged in Jira. It’s now Anoop’s turn to review his work, and he asked for the Test Cases and Test Summary Report. Raj, however, didn’t know that he needed to write test cases and make a summary report as a part of his tasks. It eventually resulted in working an additional day until those tasks are completed. And the (adverse) result – one day lost!
I hope It’s quite clear from this short example that if the team had set aside a moment of their effort to define what it meant for testing to be done upfront, they could have avoided an unnecessary delay in the delivery timeline.
This is happening at all levels of Software Development Phases. That is why at Bridge Global we follow this practice of using DoD. This is instrumental in having highly functioning Agile teams that clearly define when to call a task/effort as done or completed. Usually, this includes a lot of things from documentation, coding, testing training, updating wiki/manual, etc. This helps us to ensure that the project deliveries are happening on time with maximum quality.
Lack of DoD Leads to Poor Deliverables
A lot of people still think it’s not mandatory to have Definition of Done. They don’t understand that it’s the lack of a proper DoD which is causing issues with quality deliverables. When there is no Definition of Done for a team the team will pull more tasks/stories into the sprint than they can handle. They are doing this because they don’t realize what it exactly takes to complete the stories. The outcome would be a lot of ‘in-progress’ and ‘incomplete’ stories. As you know, when work in progress (WIP) increases, the valuable output delivered will be minimal.
Once the DoD is made, sometimes the team realizes that they can work only on a limited number of stories. But that’s totally fine and that’s what we need to discover. There is no point in having 10 stories in In-Progress. What matters is two stories that you deliver. At the end of the sprint if we have something completed that gives value to the customer, then trust me, you are on the right track!
Definition of Done VS Acceptance Criteria
I know, in the agile world, a lot of people are still confused between Definition of Done and Acceptance Criteria. Many of them assume that both are the same in some way. Actually, they are not the same but complement each other.
Definition of Done primarily focuses on quality and processes — which will help you to focus on things that need to be done in order to release or to be compliant with whatever regulations you may have in place.
Acceptance Criteria focuses on the product itself and on what this functionality must do in order to be usable by users or get accepted by the product owner.
To make it more clear, Acceptance Criteria helps you to build the right thing while Definition of Done helps you to ensure you have done it in the right way. Acceptance criteria should be a part of DoD.
At Bridge, we practice DOD in three levels, which helps us to ensure maximum quality. We never start working on something until we have agreed on the definition. It will always help us to be consistent. Be clear and have a shared understanding.
If you want to start using DoD for your teams, we would like to help you by providing a basic template which you can download below:
If you want to know more about how your project/product can get benefited out of it, feel free to get in touch with us.
About Anuraj S L
Anuraj S.L is a talented software testing professional with notable experience serving as Scrum Coach/Master in various distributed teams. He is passionate about Enterprise Agile transformation and Digital Transformation.
View all posts by Anuraj S L →
Well written with good examples. Even a common man will understand how Definition of Done is important in Software Development as well as in our daily life.