Definition of Done: How to Write and Evolve It
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 more than a checklist. 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. It ensures everyone knows what done means. Without a clear Definition of Done, teams and stakeholders will have different ideas about whether work is truly finished.
Why a Definition of Done Matters
A clear Definition of Done is fundamental to Scrum. It provides transparency. When a Product Backlog item meets the Definition of Done, an Increment is born. This Increment is usable. It means stakeholders can inspect it and provide feedback without delay. If an item does not meet the Definition of Done, it cannot be released, even if the Developers think it is ready. It is not an Increment. This clarity prevents misunderstandings and builds trust.
The Definition of Done also guides the Developers in knowing how much work to select during Sprint Planning. They must consider all the work required to meet the Definition of Done. This includes development, testing, integration, and documentation. It shapes their understanding of what it means to deliver value.
Who Creates It
If the Definition of Done for the product is part of the organization's standards, all Scrum Teams must follow it as a minimum. If it is not, the Scrum Team must create one for the product. The Developers are primarily responsible for crafting this Definition of Done. They are the ones doing the work, so they best understand what is needed to ensure quality. The Scrum Master facilitates this process, ensuring everyone understands its purpose and value. The Product Owner ensures the Definition of Done aligns with product quality expectations and market needs.
It is a collaborative effort. While Developers own the details, the entire Scrum Team should agree on it. This shared ownership helps ensure commitment and adherence.
Writing the First Definition of Done
Start simple. Do not try to capture every possible quality aspect on day one. Focus on the most critical items that ensure the Increment is usable and potentially releasable. What are the absolute minimum conditions for you to consider a piece of work complete and ready for customer use or feedback? Think about the core aspects of functionality, quality, and integration.
- Code reviewed
- Automated tests written and passed
- Integrated with main branch
- No known critical defects
- Meets security standards
- Performance acceptable
- Deployment ready
These are examples. Your team's list will be specific to your product and context. The goal is to set a baseline that the team can consistently meet Sprint after Sprint.
Evolving the Definition of Done
The Definition of Done is not static. It evolves. During each Sprint Retrospective, the Scrum Team inspects how well the current Definition of Done served them. They identify areas for improvement. As the team matures, as the product evolves, or as technology changes, the Definition of Done should be updated. A more mature team will likely have a more stringent Definition of Done, reflecting higher quality standards or more sophisticated engineering practices.
For instance, an early Definition of Done might say 'manual acceptance tests passed'. Later, it might evolve to 'automated acceptance tests passed and integrated into CI/CD pipeline'. This evolution reflects the team's growing capabilities and commitment to higher quality. The Scrum Team should always strive to improve its Definition of Done. A more robust Definition of Done usually leads to higher quality products and reduced technical debt.
Impact on Release
When multiple Scrum Teams work on the same product, they must all use the same Definition of Done. This ensures consistency and seamless integration across teams. If a Product Backlog item does not meet the Definition of Done, it is not part of the Increment. It cannot be presented at the Sprint Review as done. This discipline is crucial for maintaining product quality and the integrity of the release process. An Increment is a sum of all Product Backlog items completed during a Sprint and the value of the Increments of all previous Sprints.