Definition of “Done” for a Definition of “Done”

Scrum relies on transparency; transparency doesn’t occur overnight, but is a path. These are the statements from the Scrum Guide on which one of the key (and probably an undervalued) artifact — the Definition of “Done” is based on. What is a definition of “Done”? It’s a shared understanding of what it means for work to be complete. This is agreed by the Development Team and the Product Owner against which a “Done” increment is delivered each Sprint and a Product Owner may choose to immediately release it. So if transparency doesn’t occur overnight, when is a definition of “Done” really “Done”?

The answer is probably “never”:

Ever Evolving?

This makes the Definition of “Done” an evolving artifact and as such enables transparency over time.

Deriving a Definition of “Done”:

However, if you wish to use this, then a user story is obviously followed by acceptance tests (or criteria) that’s derived in presence of the whole Scrum Team and agreed as the basis of engineering & quality standards. The reason I prefer to call it deriving and not creating is because it’s not a one time activity. Once created, it becomes a part of the regular inspection and adaptation with inputs from the Scrum Team and affected by external constraints.

Single Team’s Definition of “Done”:

For instance, a newly formed Scrum Team during their first Sprint Planning meeting will have the Product Owner provide the vision of a new Product to build a state of the art ETL tool. The team will go through the existing Product Backlog, together derive a Sprint Goal and select Product Backlog items that it can possibly complete in one Sprint. At this point, the Scrum Master may time-box a definition of “Done” exercise and put forth the above mentioned question. As the acceptance criteria, the Scrum Team may come up with the below list:

  • All code checked in
  • All unit tests passing
  • All acceptance tests passing
  • Previous increments integrated
  • Minimum test coverage 80%
  • No open defects / bugs
  • Performance tests passing
  • Release notes updated
  • Recovery plans updated
  • Etc.

This definition of “Done” gets fed into the remaining Sprint Planning meeting where the Development Team decides how it will build the functionality defined by the Sprint Goal into a “Done” product Increment during the Sprint.

Scaled Team’s Definition of “Done”:

Also, since these teams are working on the same product, their Sprint length will probably be the same. Even if it’s not, these teams must find a common time (e.g.: combined Sprint Retrospective) where the shared definition of “Done” can be inspected. When new teams get added to this setup at a later point in time, a common definition of “Done” exercise makes sense during the first Sprint Planning of the new team to share common guidelines, agree on exceptions, and derive exclusive “Done” criteria for the new team.

Organisation’s Definition of “Done”:

Absence of Definition of “Done”?

  • Lack of shared understanding regarding when is an Increment acceptable
  • Lack of quality standards for an Increment
  • Lack of transparency between business and technical acceptance
  • Increased risk of failure due to incomplete activities
  • Negative outlook about the product in the market
  • Loss of credibility
  • Bankruptcy (a bleak possibility)

In short, there’s no “Fun” without a definition of “Done”.

Note: This blog represents only one of the aspects and ways of approaching the definition of “Done”.

Originally published at

Thoughtworker • Podcaster • Educator • Blogger • Bassist