Definition of Done

The Definition of Done is a commitment by the Developers to the Increment. Every Sprint aims to create an Increment that meets the Definition of Done and achieves the Sprint Goal.

Producing Done Increments has been described by Ken Schwaber (the co-creator of Scrum) as the most critical element of Scrum. It is a crucial enabler of the empirical approach, supporting increased transparency and enabling inspection and adaptation. Work cannot be considered part of an Increment unless it meets the Definition of Done. We have an Increment whenever work meets the Definition of Done.

The Definition of Done enables a shared understanding of what elements are required to convert a Product Backlog item into a usable Increment. In the interests of transparency, everyone must understand the Definition of Done, and the Developers must adhere to it.

Having an agreed and transparent Definition of Done makes expectations around quality clear and enables the Developers to forecast the work they can carry out in a Sprint. It allows practical inspection of the Increment and Product Backlog in the Sprint Review as everyone is aware of the work that is Done and what work is not Done.

If the Definition of Done for an Increment is part of the organisation’s standards, all Scrum Teams must follow it as a minimum. If it is not an organisational standard, the Scrum Team must create a Definition of Done appropriate for the product.

A Definition of Done is for the product, so if multiple teams build the product together, they must mutually agree and share a Definition of Done.

Done is Binary. An Increment must be Done. Almost Done or 95% Done is the same as not Done. This is in the interest of maintaining transparency around the current state of the product. Reporting on partially Done work creates confusion and risks making false assumptions about the state of the product. Work that is not Done is not inspected at the Sprint Review or released.

Scrum does not define the practices a Scrum Team should use to create a Definition of Done or what a finished example must look like. A common practice is to assemble a checklist of things that must be true for work to be considered Done. Here is a simple example of a Definition of Done for a software product:

• Code-complete and checked.
• Code reviewed.
• Code integrated.
• Code tested (unit, system, regression etc).
• Environment prepared for release.
• Support documentation updated.
• Release script & notes prepared.

Scrum Teams new to Scrum or Scrum Teams working on a new product may initially struggle and fail to produce a Done Increment. The struggle is natural and should be embraced rather than feared or avoided. A failure to achieve a Done Increment will help the Scrum Team and stakeholders better understand the challenges they currently face in building the product. Addressing this early will reduce the risk around the product over time.

If the Scrum Team cannot achieve a Done Increment, they should identify the work required to enable them to reach Done in future and add that work to the Product Backlog. This work would typically be ordered high in the Product Backlog. Work in future Sprints will include this Done, enabling work to proceed.

Practice the “Art of the possible” and work towards achieving a Done Increment as early and often as possible. Accept where this is not possible and work towards making it possible as quickly as possible.