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”:
Not to worry, that’s an answer with many things in Scrum and for good reasons. A Product Backlog for instance is never “Done”, it’s ever evolving till the existence of a product. It changes as more information is acquired around the users and the product itself. Impediments (in general) are never gone (Done); they keep coming and require facilitation. Inspection and adaptation is never “Done”; these are opportunities for continuous improvement at regular intervals. Artifacts itself may change overtime even if they provide the same information, only in a better way. Definition of “Done” is no stranger.
Ever Evolving?
Consider a situation where a development team does not have automation testing capabilities. The team will probably identify this gap during a Sprint Retrospective and have a plan to gain these capabilities overtime in order to improve the quality of the Increment. Does that mean the Increments will not be “Done” in the meantime? Of course not! The first iteration of the Definition of “Done” may have a shared agreement between the Development Team and the Product Owner to have rigorous exploratory testing for every integrated Sprint Backlog item to ensure acceptance. As the capabilities are gained within the team, the Definition of “Done” can get revised during another Sprint Retrospective to have automation testing included along with a plan to recover the technical debt that might have be injected during its absence.
This makes the Definition of “Done” an evolving artifact and as such enables transparency over time.
Deriving a Definition of “Done”:
One of the common ways of deriving a Definition of “Done” is to have an exercise during the first Sprint Planning where the Scrum Master may ask the team a simple (potential) question: As a Product Owner, I want a useable increment from this Sprint so that I may choose to immediately release it. Although this question is framed as a commonly used user story format, there is no compulsion to use it this way.
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":
Chances are bleak but you may belong to one of those lucky Scrum Teams that’s not affected by any external constraints; then you can perform this exercise all by yourself and define your own acceptance and quality standards.
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":
When working with multiple Scrum Teams towards a single Product, the definition of "Done" for each team will get influenced by the other teams. Since all the teams are working on a common product, a common set of standards will apply to all teams. Exceptions may apply to a few teams which are only acceptable if agreed by all the other Scrum Teams and the Product Owner. It's worth noting that if the multiple teams kicked-off their implementation at the same time, the rule of thumb would be to have a common definition of "Done" exercise during the first Sprint Planning.
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":
The Scaled Scrum scenario may also apply to organisations where all products and teams of an organisation are bound by a common set of guidelines. For every new product or team, it may be a mandate to have a definition of "Done" that apply these organisation conventions and more if required. Although complicated, the derivation guidelines for Scaled Scrum must also apply when conventions & standards are mandated by organisations and these must be inspected at regular intervals.
Absence of Definition of "Done"?
Yes, a definition of "Done" may never be "Done"; evolution is the only way to become better. If this becomes an excuse to not have a definition of "Done" then what happens? To list a few:
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".