What is a Definition of Done?

The meaning of a Definition of Done

“I’m almost done.” Or, “The job’s 90% done.” Maybe you’ve heard such statements before, which give hints about the progress of a task, but are not very concrete. What does “almost done” mean? Which 10% are still missing for completion?

With a Definition of Done you create clarity. By using a DoD, you know what is needed for something to be considered “finished”. This clarity does not depend on personal judgements; it is the result of agreed criteria, all of which must be met, so that an “almost finished” becomes a “finished” or “done”. In addition, a Definition of Done stands for a demand for quality, for a focus on values and procedures.

​

​Commitment to the Definition of Done

A Definition of Done stands and falls with the commitment of the team. It is the team’s claim to implement the agreed criteria in concrete terms. It is a commitment and an essential basis for the successful development of products. In order for it to have an effect, it is important that it is developed together as a team. A DoD that has only been created by the product owner does not lead to such a commitment.

In order for the Definition of Done to have the greatest possible effect, it is recommended that it be published in a way that is clearly visible to all parties involved at all times, ideally as a printout on a wall. This transparency also increases the commitment of the team to meet the agreed criteria.

​Examples of a Definition of Done

You can formulate a Definition of Done or create it as a criteria list. If you are developing software, a formulated DoD could be as follows:

“A user story is considered complete if the acceptance criteria are met, the code is generated according to standard XYZ, the code is saved in version control, the manual review by a team member and the automated tests have shown no errors, and the documentation has been adapted.”

Organisations often decide to create their Definition of Done as a criteria list, because this offers the option to tick off individual criteria separately. Such a list could include the following items, among others:

• all acceptance criteria are met
• the code is fully implemented and commented on
• the code was developed in pair programming
• the coding standards of XYZ and the internal conventions ABC were adhered to
• the code is under version management
• a code review was performed
• the unit tests were carried out and passed
• a documentation was created
• an entry has been created in the change log

When establishing a Definition of Done, teams should ensure that the established criteria are reviewed. The more criteria are defined, the more criteria need to be reviewed. If the review did not take place, the meaning of the DoD would soon become obsolete. The claim and reality must therefore fit together.

The difference to Acceptance Criteria

There is an essential difference between acceptance criteria and a Definition of Done: acceptance criteria always refer specifically to an item such as a user story. They provide more clarity as to what is to be implemented within the framework of the user story and are the source for acceptance tests. The Definition of Done, on the other hand, refers, for example, to the general work with user stories, i.e. the criteria formulated there are invariant. If, for example, developments have to undergo a peer review and a QA test before release, these criteria are reflected in the DoD and not in the acceptance criteria of the user story. In order to complete a user story, it is not sufficient simply to fulfil the acceptance criteria; the criteria of the DoD must also be fulfilled. In principle, the fulfillment of the acceptance criteria can also be a criterion for the DoD.

Advantages of a Definition of Done

Working with a Definition of Done offers several advantages:

• There is a common understanding of quality and the commitment of the team to deliver that quality. The idea of quality is more comprehensive because it refers to more than just a task or a user story.
• Everyone in the team knows what is expected of everyone and what the team has to deliver as a unit.
• The demand in the team to perform qualitative work is increasing.
• The agreed criteria can be checked, i.e. the DoD is a working tool.
• DoDs can be defined for different aspects, e.g. for user stories, features, sprints or releases. In this way, suitable DoDs can be created for topics, which can also be further developed together in a team.
• It becomes clear whether a backlog item, a feature or a user story is actually “done”.

The consistent application of the Definition of Done

Companies face several challenges when using a Definition of Done:

• How does the consistent application of a Definition of Done succeed?
• How is the interaction between different DoDs organised?

How can the Definition of Done be improved?

When using a Definition of Done, organisations sooner or later ask themselves whether it is acceptable not always to fully meet all criteria. Maybe the defined criteria are more comprehensive than originally intended, maybe in individual cases it is okay to accept technical debts? There is no universal answer to this question; it lies in a grey area. For an organisation, however, it is important to distinguish whether it will be a one-off deviation or whether the DoD should be changed permanently. The refinement of the criteria can thus lead to a reduction or, conversely, to an increase in criteria.

The use of several DoDs on different levels can lead to an overhead and a loss of transparency. If the acceptance criteria of a user story are fulfilled, the Definition of Done must be checked. The DoD for the development of user stories is obvious. In addition, the Definition of Done of the Sprint and then possibly the Definition of Done of the Release apply. Where do organisations manage the relevant information? How is a user story accepted if a criterion is not met on another level? Doesn’t working with several DoDs result in criteria at higher levels being gradually shifted in the direction of user stories? These questions, too, cannot be answered generally. In other words, organisations need to find a pragmatic way of dealing with the DoDs at different levels and, if necessary, develop not only a single Definition of Done but also the interaction of different DoDs.¹

The Definition of Done in practice

Here you can find some English and German articles that deal with the Definition of Done in practice:

• Five reasons for having a Definition of Done – article by Michael Kuesters at Fail Fast, Move On.
• Schwächen der Definition of Done in der Anwendung – article by Felix Stein at One Lean and Agility.
• Wer ist eigentlich für die Definition of Done verantwortlich? – article by Marc Kaufmann at srcum.org.
• Definition of Done Canvas – article by Rickard Jones on DZone.
• Definition of Done vs. User Stories vs. Acceptance Criteria – article at agile pain relief.
• Why Scrum Requires Completely “Done” Software Every Sprint – article by Christiaan Verwijs at scrum.org.

We would be happy to add more exciting contributions to the list.

Impulse to discuss:

Is a Definition of Done more a commitment of the team to quality or a tool for transparency?

Notes:

[1] In practice, it is more advisable to agree on a company-wide or at least a multi-team Definition of Done as a minimum standard. Individual teams can expand this standard with individually supplemented content on demand.

Here you will find DoD Kards – “A game to work out the team Definition of Done together”.

Here is an interesting German podcast on the focus and consistency for teams through the DoD.

And here you will find additional information from our Smartpedia section:

What does t2informatik actually do? One click and you'll know.