Definition of Done
The Definition of Done is a commitment by the Developers to the Increment.
The aim of every Sprint is 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 important element of Scrum. It is a key 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. Whenever work meets the Definition of Done we have an Increment.
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 better enables the Developers to forecast the work it can carry out in a Sprint. It allows effective inspection of the Increment and Product Backlog in the Sprint Review as everyone is aware of the work that Done and what work is not Done.
If the Definition of Done for an increment is part of the standards of the organisation, 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 are building 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 interests of maintaining transparency around the current state of the product. Reporting on partially Done work creates confusion and risks creating false assumptions around 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 in.
- Code reviewed.
- Code integrated.
- Code tested (unit, system, regression etc).
- Environment prepared for release.
- Support documentation updated.
- Release script & notes prepared.
New Scrum Teams, 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 currently faced in order to build the product. Addressing this early will reduce the risk around the product over time.
If a Done Increment cannot be achieved by the Scrum Team, 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.
Practice the “Art of the possible” and work towards achieving a Done Increment as early and often as possible. Accept where this is currently not possible and work towards making it possible as quickly as you can.