Definition of Done

What is a definition of Done, what advantages does it offer and what examples are there?

Definition of Done – Definition

The Definition of Done is a checklist of quality criteria that describes the conditions that must be met in order for a product to be considered completed. Since people have different ideas about quality, it is important to define a Definition of Done – also abbreviated as DoD – together in a team. Thus the responsibility for the DoD also lies with the team and it acts as a self-commitment for the team. The defined criteria can be used to determine whether a backlog item, feature or user story has actually been “completed” or “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.

Defintion of Done - a checklist with quality criteria

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

The Definition of Done in practice

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

 

Do you know the difference to the Definition of Ready?

What is the Definition of Ready, who is responsible for it, and how should it be formulated?

Challenges for companies

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.

We are happy to provide you with knowledge, experience and 100% passion for your software development and requirements analysis. We help you with the collection, structuring and administration of requirements and pay attention to consistency, completeness and traceability. We support you in identifying technical correlations and consider stakeholders, goals and boundary conditions. And we realise your requirements taking into account your Definition of Done.

Find out more about software development here  »

More details and information ...
Share This