People may not see the point when they hear about the Definition of Done in Scrum. They may say, "We are so sick of talking about the Definition of Done," or “Why does this matter?”
First and foremost, what is a Definition of Done? The Definition of Done (DoD) in Scrum is a set of criteria determining when a Product Backlog item can be considered complete. Sounds simple, right? And perhaps a little pointless?
Nothing could be farther from the truth. Consider this: when you bake a batch of cookies, when are you ‘done’? Is it when the cookies are baked? Or when the kitchen is clean? If we don’t have a straightforward answer about a batch of cookies, imagine how much more grey area there might be in something as complex as software development.
Without a clear agreement about a Definition of Done, some developers may think they are done after the code is complete. Others may think a code review is needed before the work can be considered done. Still, others may think the work is done when it has been unit tested but before regression testing is done.
The Definition of Done is a document that clarifies these questions. It is an agreement that describes all the work needed for each Product Backlog item before it can be considered Done.
Below are ten benefits of a clear Definition of Done for the Scrum Team.
Prevents misunderstandings among Developers. Without a clear set of completion criteria, team members may interpret tasks differently, leading to outcome discrepancies. This lack of alignment can result in rework, misunderstandings, and delays. Teams can minimize such ambiguities by establishing a shared understanding of what "done" means.
Improves Sprint Planning. The DoD also helps Developers plan the Sprint better because it clarifies how much work needs to be done for each Product Backlog item before it can be considered Done. This helps the Developers better understand how much work can be pulled into the Sprint and improves the likelihood of the team being able to deliver a done increment at least once per Sprint.
Improves the accuracy of forecasting progress against the Product Goal. At the Sprint Review event, progress towards the Product Goal is discussed. Without a clear understanding of what has been Done, it would be hard to discuss progress toward the goal accurately. The Definition of Done helps the Product Owner create an accurate forecast of progress toward the Product Goal by providing transparency about the state of the increment delivered each Sprint.
Prevents the accumulation of additional technical debt. Technical Debt refers to Developers' decisions to trade quality for speed. Technical debt can be incurred unconsciously or consciously. Examples of unconscious accumulation of technical debt may be bugs introduced into the software because of poor programming decisions. Examples of the conscious accumulation of technical debt might be hard coding values that should be dynamic to save time during development. Not all technical debt is bad, but the constant accumulation of technical debt can lead to a poor-quality product. Scrum Teams can use the DoD to prevent the accumulation of technical debt by adding criteria such as code reviews, code comments or code refactoring to the Definition of Done. By adding rigorous criteria intended to improve product quality, the team reduces the accumulation of unconscious technical debt in the product.
Improves product quality. The DoD can improve product quality by adding standards around the product delivered by the Scrum Team. Standards such as security requirements or code reviews can enhance overall product quality when included in the DoD.
Adds transparency for stakeholders. The DoD also provides transparency for stakeholders so that everyone understands the state of the increment being delivered when work is demonstrated at the Sprint Review. For example, if testing and integration are part of the Definition of Done, then only tested and integrated work is shown at the Sprint Review.
Improved transparency aids in inspection and adaptation. Scrum implements empirical process control or making decisions based on what is known. The three pillars of empiricism are transparency, inspection, and adaptation. By improving the transparency around what is included in a done increment, the Definition of Done enables the team to honestly inspect progress and make better decisions about what to do next.
Reduces administrative burden for the Scrum Team. This may surprise some people, but by taking the time to document a Definition of Done, the Scrum Team actually reduces their administrative burden. For example, if the Scrum Team has created a Definition of Done that includes testing, code review, and security scanning, then they do not need to include these tasks on every Product Backlog item.
Streamline quality standards in the organization. Creating an organizational-wide Definition of Done that all Scrum Teams must adopt, at minimum, can be a very efficient way to ensure that all Scrum Teams adhere to required technical practices within the organization.
The Product Owner can influence quality expectations. The Scrum(s) supporting a Product create a DoD (and if an organizational DoD exists, they must adopt that at minimum). This means that the Product Owner—as part of the Scrum Team—discusses what should be included in the DoD. This is an important way for the Product Owner to influence the quality expectations for the Product.
Conclusion
It's important to recognize that the Definition of Done is not a static document but a living artifact that evolves as the product evolves. As the team becomes more advanced at Product Delivery, they may adopt more rigorous standards in their Definition of Done, resulting in decreased technical debt accumulation and higher product quality. The Scrum Team should regularly review the DoD to determine whether it should be adapted to promote enhanced product quality. These discussions should take place at the Sprint Retrospective. To learn more about the Sprint Retrospective, check out our recent article The Power of the Sprint Retrospective.
There are numerous benefits to a Definition of Done, but consider this: The entire purpose of Sprint is to deliver a done, usable increment at least once per Sprint. Shouldn’t we be clear about what done means to us in our context?
So, the next time you discuss the Definition of Done with your Scrum Team, remember that flying through hyperspace is a lot more complicated than dusting crops or baking cookies - so is product delivery!
Get tickets for the most exciting Scrum Day conference with speakers from Space Force and leading trainers like Stephanie Ockerman, Mary Iqbal, Todd Miller, and more! Get tickets at www.ScrumDay.org.