Definition of Done: A Practical Guide
Understand the Definition of Done in Scrum. Learn how to write a clear, concise Definition of Done and evolve it over time for continuous improvement.
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 not an optional extra. It is a commitment that ensures transparency. Without a clear Definition of Done, a Scrum Team cannot truly say an item is finished. This creates confusion and risks delivering incomplete work. This post explains how to write and evolve a strong Definition of Done.
What the Definition of Done Does
The Definition of Done brings clarity. It creates a shared understanding among the Scrum Team and stakeholders about what 'Done' means. This shared understanding reduces misunderstandings and improves predictability. It is applied to every Product Backlog item selected for a Sprint. An Increment is only truly 'Done' when it adheres to this definition.
For example, if the Definition of Done states 'code reviewed', then any Product Backlog item that has not undergone a code review is not Done, regardless of whether the code compiles and runs. This consistency is crucial for quality and transparency.
Who Creates It
The Scrum Team is responsible for creating the Definition of Done. If the organization has standards for what 'Done' means, the Scrum Team must incorporate these into their own Definition of Done. This ensures alignment with broader company quality requirements. If there are no organizational standards, the Scrum Team must create one that is appropriate for their product.
This team ownership is vital. It ensures the Definition of Done is practical and reflects the team's capabilities and context. It is not imposed by management or external groups. The Developers, Product Owner, and Scrum Master collaborate to define what quality means for their work.
Writing Your First Definition of Done
Start simple. Do not try to capture every possible quality check on day one. Focus on the essential elements that define a releasable increment. The goal is to set a baseline that the team can consistently meet. This early version should be concise and understandable to everyone involved.
Consider these common elements when drafting an initial Definition of Done:
- Code reviewed
- Unit tests written and passing
- Integrated with main branch
- Meets acceptance criteria
- No known critical defects
- Documentation updated
These items provide a solid foundation. Adjust them to fit your specific product and technology stack. The most important thing is that the team agrees on them.
Evolving the Definition of Done
The Definition of Done is not static. It is a living artifact that evolves. As the team learns more about the product, technology, and customer needs, they will identify new quality requirements. The Scrum Team should inspect and adapt their Definition of Done during Sprint Retrospectives. This is a key part of empiricism in Scrum.
When the team consistently meets their current Definition of Done, they should aim to raise the bar. For example, if 'automated integration tests pass' becomes a consistent practice, it can be added. This continuous improvement leads to higher quality products over time. It also helps the team identify and address technical debt or process gaps.
Impact on Transparency and Quality
A strong Definition of Done ensures transparency. Everyone knows what to expect from a 'Done' increment. This transparency builds trust with stakeholders. It also provides a clear quality gate. Work that does not meet the Definition of Done is not considered part of the Increment. This prevents incomplete or shoddy work from accumulating.
Ultimately, a well-crafted and evolving Definition of Done drives product quality. It enables the Scrum Team to deliver valuable, usable Increments consistently. This commitment to quality is fundamental to the success of any Scrum effort.