Definition of Done: Writing and Evolving One

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 commitment by the Scrum Team. Without a clear Definition of Done, a team might think work is finished when it really is not. This leads to hidden work, technical debt, and a false sense of progress. A robust DoD ensures transparency and provides a shared understanding of what it means for work to be truly complete and ready for use.

Why a Definition of Done Matters

The DoD creates transparency. Everyone, from the Developers to stakeholders, understands the quality bar. When a Product Backlog item meets the Definition of Done, it means the item is potentially shippable. This is crucial for empiricism. If an Increment is not truly Done, the team cannot accurately inspect and adapt based on real feedback. It also helps the Developers make informed decisions about how much work they can realistically pull into a Sprint.

For example, if a team says a feature is Done but it has not been tested by Quality Assurance, it is not truly Done. The DoD prevents this ambiguity. It pushes quality activities earlier in the development cycle, reducing the cost of fixing defects later. It aligns the team on what 'ready for release' actually means, reducing confusion and rework.

Crafting Your Initial Definition of Done

The Scrum Guide states that if multiple Scrum Teams are working on the same product, they must mutually define and comply with the same Definition of Done. If no organizational standard exists, the Scrum Team must create its own. This is not a task for just one person. The entire Scrum Team, including the Product Owner and Scrum Master, should collaborate to define it. They bring different perspectives that are all necessary.

Start with what is absolutely necessary for a usable increment. Think about what would prevent you from releasing the product to users today. Common items include: code complete, reviewed, tested, and integrated. Avoid making it too aspirational at first. Focus on the basics that ensure a minimum level of quality and functionality. You can always improve it later.

Common Elements of a Definition of Done

While every team's DoD will be unique, reflecting their specific product and context, some elements are almost universally present. These ensure a basic level of quality and readiness. Consider including items like:

• Code is written and committed to version control.
• Code has passed automated unit tests.
• Code has passed automated integration tests.
• Code has been peer reviewed by another Developer.
• Functionality has been tested by Quality Assurance.
• Acceptance criteria are met and verified.
• Documentation, if required, is updated (e.g., user guides, API docs).
• Performance and security checks are completed.
• Product Backlog item meets the product's quality standards.
• Integrated into the main codebase.

Evolving Your Definition of Done

The Definition of Done is not static. It is a living document that evolves with the team and the product. The Scrum Team inspects and adapts it during the Sprint Retrospective. As the team matures, gains new skills, or encounters new challenges, they should refine their DoD. For example, a new team might not have automated tests initially. As they build their testing infrastructure, they can add 'automated tests passed' to their DoD.

This evolution should always aim to increase quality and reduce future work. If the team consistently finds bugs after an item is declared Done, that is a clear signal to strengthen the DoD. If they discover new technologies or practices that improve quality, those should be incorporated. The goal is continuous improvement, making 'Done' mean something more robust over time.

The Impact of a Strong DoD

A well-defined and consistently applied Definition of Done has several positive impacts. It reduces technical debt by forcing quality practices into each increment. It builds trust with stakeholders because they know what 'Done' truly means. It empowers the Developers by giving them clear boundaries and expectations. They can self-manage more effectively when they know the quality bar.

Ultimately, a strong Definition of Done is a cornerstone of effective Scrum. It enables empiricism, supports transparency, and ensures that every Increment delivered is a true step forward for the product and its users. Invest the time to define it carefully and commit to evolving it regularly.

Start with the Foundations module →

Or take the full Scrum Master track →