Scrum relies on transparency, inspection, and adaptation; transparency requires courage and trust. The team can only inspect work, progress, and quality when they are transparent. Without inspection, there is no adaptation.
These are the core principles of the Scrum Framework, and the Definition of Done is a commitment by the Scrum Team to make the Increment transparent.
So what is the Definition of "Done"?
It's a shared understanding of what it means for work to be complete. The Scrum Team agrees to deliver the "Done" Increment in each Sprint, and a Product Owner may choose to release it immediately.
So if transparency doesn't occur overnight, when is a definition of "Done" really "Done"? Let’s understand this further.
The answer is probably "never"
Not to worry, that's an answer to 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 about the users and the product itself.
Impediments (in general) are never gone (Done); they keep coming and require facilitation. Inspection and adaptation are never "Done"; these are opportunities for continuous improvement at regular intervals.
Artifacts themselves may change over time even if they provide the same information, only in a better way. The 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 plan to gain these capabilities over time to improve the Increment's quality.
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 Developers 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 been 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, we want a useful increment from this Sprint so that we can choose to release it immediately. 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 are derived in the presence of the whole Scrum Team and agreed upon as the basis of engineering & quality standards. I prefer to call it deriving and not creating 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 is affected by external constraints.
Single Team's Definition of "Done"
Chances are bleak, but you may belong to one of those lucky Scrum Teams unaffected by any external constraints; then, you can perform this exercise yourself and define your own acceptance and quality standards.
For instance, during their first Sprint Planning meeting, a newly formed Scrum Team 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, 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 the "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 to 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 toward 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 upon by all the other Scrum Teams and the Product Owner. It's worth noting that if multiple teams kicked off their implementation simultaneously, the rule of thumb would be to have a common definition of the "Done" exercise during the first Sprint Planning.
Also, since these teams are working on the same product, their Sprint length will likely be the same. Even if it's not, these teams must find a common time (e.g., combined Sprint Retrospective) when 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 the "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.
Organization's Definition of "Done":
The Scaled Scrum scenario may also apply to organizations where a common set of guidelines binds all products and teams of an organization. For every new product or team, it may be a mandate to have a definition of "Done" that apply these organization conventions and more if required. Although complicated, the derivation guidelines for Scaled Scrum must also apply when organizations mandate conventions & standards, which must be inspected regularly.
Absence of Definition of "Done"?
Yes, a definition of "Done" may never be "Done"; evolution is the only way to improve. If this becomes an excuse not to have a definition of "Done," then what happens? To list a few:
- Lack of shared understanding regarding the acceptance of the Increment
- 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."
Our vision is to become one of the trusted groups of passionate change agents to build ecosystems in enterprises to scale digital solutions.
