Definition of Done: From Creation to Constant Refinement
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a shared understanding.
The Definition of Done is not a suggestion. It is a formal description of the state of the Increment when it meets the quality measures required for the product. It creates transparency by providing a shared understanding of what work was completed as part of the Increment. Without it, the Increment is not truly done. The Scrum Guide is clear: if an item in the Product Backlog does not meet the Definition of Done, it cannot be released, or even presented at the Sprint Review. It simply returns to the Product Backlog.
Why a Definition of Done Matters
A clear Definition of Done reduces ambiguity. It means everyone, from Developers to Product Owner to stakeholders, understands what "done" truly means for any given Product Backlog item. This prevents misunderstandings and ensures quality. Without it, "done" is left to individual interpretation, leading to inconsistent quality and potentially incomplete work being presented as finished. It is a commitment by the Scrum Team, helping them to self manage and deliver valuable Increments consistently.
Writing Your Initial Definition of Done
The entire Scrum Team is responsible for creating the Definition of Done. If there are multiple Scrum Teams working on the same product, they must mutually define and comply with the same Definition of Done. This ensures consistency across the product. Think about the fundamental steps required for any piece of functionality to be truly releasable. Start with the basics. What are the non-negotiable quality criteria for your product?
- Code reviewed by another Developer.
- Automated tests written and passing.
- Integrated into the main codebase.
- Documentation updated for new features.
- Meets security standards.
- Performance benchmarks met.
These are examples. Your team will have specific needs. Do not make it an exhaustive list of every possible task. Focus on what makes an Increment truly usable and releasable. It should represent a 'shippable' state, even if the Product Owner chooses not to release it immediately.
Evolving the Definition of Done
The Definition of Done is not static. It is a living document that evolves as the Scrum Team learns more about the product, its users, and the technological landscape. During each Sprint Retrospective, the Scrum Team should inspect how well the Definition of Done served them and what improvements could be made. As the team matures and improves its practices, the Definition of Done should become more stringent, reflecting a higher standard of quality.
For example, a new team might start with a simple Definition of Done that includes only basic code review and testing. As they gain experience, they might add items like performance testing, accessibility checks, or user acceptance testing sign-off. This continuous improvement ensures that the quality of the Increment consistently rises. A more robust Definition of Done makes future development easier, not harder, by baking quality in from the start.
When External Standards Apply
Sometimes, the organization or industry mandates specific quality standards. In such cases, the Definition of Done must incorporate these requirements. For instance, if you are developing software for a regulated industry, compliance checks will be part of your Definition of Done. The Scrum Team should ensure their Definition of Done encompasses all necessary internal and external standards. If the organizational Definition of Done is not sufficient for the product, the Scrum Team must add to it. The team's Definition of Done must always meet or exceed the organizational standard.
Impact on Transparency and Flow
A well maintained Definition of Done directly impacts transparency. Everyone knows the true state of work. This clarity helps the Product Owner make informed decisions about releases. It also helps the Developers manage their work effectively, knowing exactly what is expected for each item. By consistently meeting a robust Definition of Done, the team builds a rhythm of delivering high quality, usable Increments, improving flow and predictability for the entire product development effort.