Definition of Done Theses

Given the importance of a viable Definition of Done for a Scrum team’s success, it has always puzzled me how complacent or ignorant many Scrum teams are regarding their Definition of Done. So, let me share with you the ten first principles of this critical Scrum success factor to improve your team’s effectiveness, team spirit, and reputation.

The Purpose of the Definition of Done According to the Scrum Guide

The Scrum Guide characterizes the Definition of Done as follows:

“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” 

“The moment a Product Backlog item meets the Definition of Done, an Increment is born.” 

“The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.”

“If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.”

“The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.”

Source: Scrum Guide 2020.

The Scrum Guide frequently mentions the Definition of Done to underline the importance of a widely known and accepted quality standard for a successful Scrum team and organization. There is no business agility to be earned without technical excellence and high product quality—both are reflected and supported by the Definition of Done. 

For the following quotes from the Scrum Guide, please note that the number at the beginning of the sections refers to the page in the official English PDF of the official Scrum Guide:

• Page 5: However, the Developers are always accountable for instilling quality by adhering to a Definition of Done.
• Page 6: The Scrum Master serves the Scrum Team in several ways, including helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
• Page 7: During the Sprint, quality does not decrease.
• Page 8: [Sprint Planning: What can be Done this Sprint?] Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
• Page 8: [Sprint Planning: How will the chosen work get done?] For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done.
• Page 10: The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.
• Page 10: [Artifact commitment:] For the Increment it is the Definition of Done.
• Page 10: Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
• Page 12: Work cannot be considered part of an Increment unless it meets the Definition of Done.
• Page 12: The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
• Page 12: The moment a Product Backlog item meets the Definition of Done, an Increment is born.
• Page 12: The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.
• Page 12: If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. 
• Page 12: Instead, [an undone Product Backlog item] returns to the Product Backlog for future consideration.
• Page 12: If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum.
• Page 12: If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriately for the product.
• Page 12: The Developers are required to conform to the Definition of Done.
• Page 12: If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

Source: This aggregation of quotes is from the Scrum Guide 2020 — Reordered.

Definition of Done Success Principles

My top-ten Definition of Done success principles—in no particular order—are as follows:

1. There is a Definition of Done: This should be a no-brainer: Without a quality standard defining what constitutes deliverability, your Scrum team will face a slow but steady decline of its technical foundation, inevitably accumulating technical debt. If your organization’s strategic goal is becoming an agile organization and embracing business agility, you have already lost at this stage. Business agility requires technical excellence, and the Definition of Done is essential to achieve and hold that level.
2. Done means deliverable: The state of “done” as defined by the Definition of Done implies that we can deliver Increments to our customers without legal, financial, or ethical repercussions. Once a Product Backlog item meets the Definition of Done, it does not require any other form of approval, not by the Product Owner and certainly not by any “quality gate,” to release an Increment.
3. Adapt the (organizational) Definition of Done to the needs of your Scrum team: Whenever the organization provides a standard Definition of Done, consider it the smallest common denominator on quality. However, then adapt this Definition of Done to the needs of your customers or Scrum team.
4. Transparency: The Definition of Done can only live up to its potential as a universal quality standard if everyone in the organization has access to and understands it. Hiding the Definition of Done will prevent it from working outside the Scrum team. An excellent way to make the Definition of Done transparently is by including your stakeholders in its creation; see the following principle.
5. Make creating or adapting the Definition of Done a collaborative effort: Contrary to popular belief, it is not the Developers’ task to create a Definition of Done but a task of the whole Scrum team. So, now that this is established, why don’t you expand the group further by asking stakeholders and subject matter experts to join? For example, run exercises to learn your constituents’ understanding of “done” and quality. Of course, it is still the responsibility of the Scrum team to finalize its Definition of Done. Nevertheless, including others in the process will help to build trust.
6. Regularly inspect and adapt the Definition of Done: Your Definition of Done isn’t static but evolving. As the Scrum team learns more about the problem and solution space, it will want to branch out and absorb previously adjacent areas of your Definition of Done to reduce dependencies and improve its level of self-management. (Please note that branching out requires building trust among stakeholders first. Your Scrum team cannot blitzkrieg itself into that position.) An effective way to understand whether your Definition of Done needs an upgrade is to run anonymous surveys among team members and stakeholders regularly.
7. Sell your Definition of Done: You need to pitch the idea of a self-managed quality standard to the rest of the organization. Selling the Definition of Done is particularly necessary when the organization otherwise believes in Q&A departments, quality gates, or “hardening Sprints.” A proven way to do this is to invite your stakeholders to participate in the creation of your Scrum team’s Definition of Done.
8. “Good enough” works for the Definition of Done: The Definition of Done is not about squeezing the maximum quality level out of available technology. Your team’s level of quality needs to meet customer expectations, governance requirements, and common ethical or moral standards. There is no need for gold-plating or “Rolls-Roycing” in everything you build.
9. Don’t show or deliver undone work: If “done means deliverable” is a critical success factor for every Scrum team, we ignore whatever we are working on until it reaches that level during the Sprint Review. This is a strong conviction, firmly held for the vast majority of all work. Until it isn’t, for example, in the case of emergency: imagine the mega-critical bug that needs immediate fixing; some improvized solution might be okay until you come up with the real thing shortly after. Or think of the critical milestone a cash-strapped startup needs to accomplish for the subsequent funding round—who wants to die in beauty? However, the unifying thing in these examples is the same: you deliver a crappy version to stem the tide now and then the real, the “done” version as soon as possible. 
10. Never abandon the Definition of Done: There is absolutely no deliberate corner-cutting in Scrum, for example, ditching your Definition of Done to meet an arbitrary deadline; see above. However, if your stakeholders pull delivery dates out of thin air, you must address this collaboration anti-pattern within the organization. Somehow, they do not seem to trust your Scrum team. Find out why and fix the underlying issue instead of violating your team’s Definition of Done to “make things work.”

Conclusion

The Definition of Done is an essential stepping stone for the Scrum team to deliver an Increment of expected quality. It provides a good return on investment from the team’s perspective and should guide the Scrum team towards accomplishing the Product Goals. Neglecting the Definition of Done will slowly but steadily erode the team’s capability to solve the customers’ problems, its reputation, and its contribution to the organization’s sustainability.

How are you dealing with the Definition of Done? Please share your learnings with us in the comments.