Listen to the Deliver It Podcast to hear Tom talk in detail about what the definition of done means to him!
Introduction
Sometimes something is so basic you don’t even think about it. You probably looked at the title of this article and said to yourself, “I know what “done” means. Are you kidding me?!?” Just hold on; the meaning of “done” can be very different for different people. For instance, I have two teenage boys, and part of their chores is to clean up the kitchen after dinner. More times than not, they will say, “Ok, I’m all done!” but when we go out and look at the kitchen, the countertop needs to be wiped down, or the sink needs to be cleaned out. Our teenagers’ definition of “done” is much different than my wife’s and my definition of “done”!
The same can hold true with software development. What does “done” mean to each person on the Scrum team? Does it mean the same to a developer as it does to the Product Owner? Does it even mean the same to two different developers on the team? Having a clear definition of what “done” really means is critical to your team producing consistent results.
What is a Definition of Done?
A definition of done is a bullet list of requirements that need to be met before a user story or bug can be considered done or shippable. This list is shared with all members of the Scrum team and all stakeholders and should cover everything needed to put that user story in a “shippable” state. That means all coding requirements, quality requirements, performance requirements, and documentation requirements are complete.
Why is it important to use a Definition of Done?
The main reason for using a definition of done is to ensure that all team members and stakeholders agree on what work needs to be completed before a story is considered shippable. In addition to this, there are a few more subtle advantages:
- Code is ready to be deployed to production at any time. Because the stakeholders and product owner can decide to deploy completed stories to production at any time, it is critical that all stories that are “done” are at a production-ready level of completeness. This is a shared responsibility of all the members of the Scrum team. The list of requirements ensures that everyone on the team has the same understanding of what needs to be completed before a user story or feature can be finished and is ready to go to production.
- Minimizes last-minute delays. We have all had experiences of putting out a new release only to find that someone forgot to do a key step. The release is delayed so someone can frantically resolve the issue. Working quickly, the person may create further issues that need to be resolved before the new version can be released. These types of last-minute delays can be minimized if a good definition of done is being used on every single user story.
- The team understands how much work it is to truly complete a story. If everyone on the team understands all the moving parts that need to be completed, in order to call a story “done,” the team has a true understanding of where each story stands and where the product stands overall. This knowledge is also highly valuable when estimating the effort required to complete future stories.
Sharing the Definition of Done
I’ve mentioned a few times that the definition of done needs to be shared with the development team. This is a critical point to using the definition of done correctly. If the product owner is the only team member who knows there is a definition of done, there is a big problem. For example, the product owner may ensure all acceptance criteria are working correctly, but they have no way to confirm all unit tests are properly written. Without proper unit test coverage, there is a huge risk of future bugs popping up. By including a ‘unit test coverage’ item in the definition of done, the product owner has visibility into all actions required to confidently consider a user story done.
By sharing the definition of done with the entire Scrum team, everyone contributes to completing the user story. With this shared responsibility, team members look out for each other to ensure all requirements in the definition of done are being met and continuously improved upon.
Similarly, it’s equally important the definition of done is shared with the stakeholders. There may be additional company requirements the development team did not think of; security requirements and data protection requirements are good examples. When all team members and stakeholders have buy-in on what makes a user story shippable, they all have confidence in the product being built.
It goes without saying, if you are working with a software development partner to develop your software, it should be compulsory they produce a definition of done that meets the requirements of the project stakeholders.
What should the Definition of Done Include?
Whether agreeing on a definition of done with your own team, an outsourced software development team, or with a software development partner like Ascendle, the definition of done is not a valuable tool unless it includes all the requirements to make a story shippable. An example of a definition of done could be:
- All required unit tests are added and are passing.
- All new code is reviewed.
- All acceptance criteria are satisfied.
- All manual and automated QA testing are completed and passing.
- All bugs have been fixed.
- The completed user story has been successfully integrated with all other code completed to date.
- All functionality meets the documented performance requirements.
- No code is in the product that does not meet this definition of done.
- The product owner has reviewed the user story after it has been integrated with the completed code.
- All documentation for the user story has been created.
Using the Definition of Done
Having the best definition of done in the world does no good if it’s not being used. Using a definition of done properly requires discipline, and the benefits are enormous. I suggest creating specific tasks in each user story that cover the requirements laid out in the definition of done. For us, we use typical sub-tasks in Jira that we create for each user story we work on. A team member volunteers to complete a particular sub-task in support of addressing that definition of done requirement. Using this approach allows us to consistently complete all of the requirements of our definition of done. It also allows us to see how much work is left to complete all the remaining requirements. This provides us with an understanding of how much work is left to complete the story.
This is an example of what the sub-tasks might look like for one user story. In this case, we use Jira to plan out the user story.
Conclusion
After I learned about the benefits of using a definition of done, I talked to my wife about using this approach for our teenagers’ house chores. We sat down with our kids and created a bullet list of what needs to be completed to consider a chore “done.” We printed the bullet list on paper using a large font, and it now sits on our fridge. Now, when the kids say, “I’m all done!” we just say, “have you checked the list?” They know what this means! Believe it or not, since we have started using this concept, they are proud of the work that they do and the fact that it is truly “DONE”!
