Don’t Mess With the Definition of Done

TL; DR: The Definition of Done - Business Agility and Technical Excellence

Most of the time, stakeholders are not interested in how we solve their problems as long as we ethically play by the rules. Instead, they are interested in the regular delivery of valuable Increments, as these pave the road to business agility. However, there is no business agility without technical excellence, which brings us to today’s topic: the importance of an actionable Definition of Done.

Learn more about twelve success principles of employing such a Definition of Done as a Scrum team to help your organization become agile.

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

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. 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

While an adequate Definition of Done does not guarantee a Scrum team’s success, its absence certainly accelerates its failure.

Without a Definition of Done, the quality of a Scrum team’s work will likely vary widely, and the level of undone or low-quality work will accumulate over time, contributing to a rising level of technical debt and increasingly inhibiting your agility.

Success Principles of the Definition of Done

The purpose of the Definition of Done is to allow the Scrum team to regularly deliver valuable Increments, which team members and stakeholders can subsequently inspect compared to the established, well-understood quality standard.

In the context of a successful Scrum team and organization, building Increments to the specifications as defined by the Definition of Done means that the team can deliver a done Increment into the hands of the customers. Moreover, delivery happens without any legal, ethical, or financial repercussions. In that respect, a Definition of Done tailored to the context of a Scrum team, its organization, and customers are the cornerstone of any form of business agility.

From that perspective, let us skip the rookie mistake of not having a Definition of Done in the first place and delve right into twelve winning principles to reap the benefits of a Definition of Done to your team’s and organization’s advantage:

1. Definition of Done’s binary nature: As a team, you either meet the quality standard defined by the Definition of Done or you don’t. Nothing fits the description: “It is practically done; I will create a bug ticket for a tiny issue I still have to solve next Sprint.” 
2. We don’t throw anyone under the bus: Done means done, which means releasable to our customers without repercussions, see above. Whenever someone on the team says a Product Backlog item is done, there is no further need for inspection. By the way, this principle does not prevent you from having peer reviews.
3. There are no approval gates: The Product Owner does not accept work accomplished by the Developers, nor do stakeholders accept the work of the Scrum team.
4. Experimenting is okay: A Definition of Done does not prevent your team from experimenting with live data from the production environment. Product discovery aims to identify worthwhile investments in your product or service on behalf of your customers as affordable as possible. If you validate hypotheses with prototypes—as you should—you will probably move from a low-fidelity prototype, for example, a clickable mock-up, to a high-fidelity prototype including actual data. If you applied the Definition of Done to building the latter, you would negate the idea of validating hypotheses with experiments. However, ensure that you refactor everything once you decide to turn the high-fidelity prototype into a real feature. A lot of technical debt is created by ignoring this necessity, particularly in the startup environment: “Shall we die in beauty? It works, so let’s move on; we will fix it later.”
5. No cutting corners: To meet an ambitious deadline, the Developers temporarily lower the quality level in some less critical parts of the application, determined to fix these parts later. The stakeholders, though, love the new-found flexibility and continue pushing the team with arbitrary deadlines, turning an exception into the new normal. Probably, you already know this scenario which, in my experience, is a sure path to disaster. Therefore, never compromise your Definition of Done. 
6. No degradation of the Definition of Done: It is a human impulse to solve mounting problems of your Increments with your quality standard by watering down the latter to a better “manageable level.” Why burden yourself with problems when you can refine the nature of the situation by lowering the Definition of Done? However, cheating yourself out of the challenge is not an option. Playing the long game requires us to deal with the underlying issues instead.
7. The defensive Definition of Done: Once bitten, twice shy. Since failure is not an option, the organization encourages to reflect this notion in the teams’ Definition of Done, strangling agility in the process with red tape. Playing safe to the maximum in a complex environment inevitably comes at a price. 
8. Product Owners are vested in the Definition of Done: Creating value in a complex environment within the existing constraints while contributing to the organization’s sustainability is an infinite game. Set yourself up accordingly, as cutting corners and turning a blind eye will cost you in the long run with a compounding effect. If tomorrow’s deliverability is your concern as a Product Owner, invest in maintaining your technical foundation continuously; your team’s Definition of Done is the lynchpin for that mission.
9. Crowdsourcing the Definition of Done: Ultimately, the responsibility of creating the Definition of Done rests with the Scrum team. However, listening to other voices, such as those of the stakeholders, is also a proven practice. Live up to the opportunity to break out of your confirmation bubble and create trust at the same time.
10. Definition of Done versus Acceptance Criteria: A simple rule of thumb applies here: if a condition is valid for all Product Backlog items, it deserves to be part of the Definition of Done. It is probably an acceptance criterion if it applies only to an individual Product Backlog item. 
11. The Definition of Done requires maintenance: The Definition of Done is not static. Once you establish its first version, the Scrum team needs to inspect and adapt it regularly. In my experience, once a team becomes more familiar with the problem and solutions space, it branches out into adjacent areas of its work to increase quality levels and deliverability. Good indicators that your Definition of Done needs an inspection and adaption are, for example, metrics such as the number of bugs that escaped to production or customer complaints.
12. The Definition of Done doesn’t have a sibling: Some teams are tempted to counter or balance the Definition of Done with a “Definition of Ready,” thus covering the flow of work into the Product Backlog. While a checklist of this nature may act as training wheels for novice teams, I doubt its effectiveness for an experienced team. The latter typically has a mature Product Backlog refinement process making a Definition of Ready obsolete. Eliminate red tape whenever possible. Believe it or not, a Definition of Ready Jira plug-in is available, just search Atlassian’s marketplace. 

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 toward 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.