Definition of Done

The DoD is not merely a suggestion; it is a mandatory set of criteria that applies to all work completed within a Sprint. When a Product Backlog Item meets the DoD, it means it is in a usable, potentially releasable state, regardless of whether the Product Owner decides to release it immediately. This commitment to quality and readiness is a cornerstone of Agile principles, particularly the emphasis on delivering working software frequently.

History and Evolution

The concept of a "Definition of Done" gained prominence with the rise of Scrum. Early Agile practitioners recognized the ambiguity inherent in simply stating a task was "finished." Without a clear, shared understanding, "finished" could mean different things to different team members – one might consider code written as "done," while another might require it to be tested, documented, and deployed. This ambiguity often led to rework, quality issues, and missed expectations.

The Scrum Guide, a foundational document for Scrum, explicitly defines the DoD as a critical artifact. Over time, its importance has been reinforced across various Agile frameworks and practices, becoming a standard practice for teams aiming for high quality and predictable delivery. It evolved from informal agreements to a formal, explicit commitment, driven by the need for transparency and inspection.

Purpose of the Definition of Done

The primary purposes of the DoD are:

• Ensuring Quality: It establishes a baseline for quality, ensuring that all completed work meets a minimum standard before it is considered complete. This prevents the accumulation of technical debt and reduces the likelihood of defects.
• Creating Transparency: By making the criteria for "Done" explicit, the DoD fosters transparency within the team and with stakeholders. Everyone understands what to expect from a "Done" increment.
• Building a Shared Understanding: It eliminates ambiguity and ensures that every team member has the same understanding of what it means for work to be complete. This shared understanding is crucial for effective collaboration and self-organization.
• Facilitating Inspection and Adaptation: During events like the Sprint Review, the DoD provides a clear benchmark against which the Increment can be inspected. If the Increment doesn't meet the DoD, it's a clear signal for adaptation.
• Supporting Predictability: A consistent DoD helps teams understand their true velocity and capacity, as they are always accounting for the full scope of work required to deliver a high-quality increment.
• Reducing Rework: By front-loading quality activities, the DoD minimizes the need for rework later in the development cycle, saving time and resources.

Relationship to Other Knowledge Topics

The Definition of Done is deeply intertwined with several other Agile concepts:

• Increment: The DoD defines the quality standards for the Increment, which is the sum of all Product Backlog Items completed during a Sprint and the value of the increments of all previous Sprints. A "Done" Increment is usable and potentially releasable.
• Quality: The DoD is a direct manifestation of a team's commitment to quality. It operationalizes quality standards into actionable criteria.
• Transparency: A clear and visible DoD is a key information radiator, promoting transparency about the state of work.
• Working Agreements: While the DoD focuses specifically on the quality of the product, it often complements Working Agreements, which define how the team collaborates and operates.
• Sprint Review: The DoD is the standard against which the Increment is evaluated during the Sprint Review. Only items meeting the DoD are presented as "Done."
• Technical Debt: A robust DoD helps prevent the accumulation of Technical Debt by ensuring that necessary quality steps (like testing and refactoring) are completed as part of every item.
• Continuous Integration and Continuous Delivery: A strong DoD is a prerequisite for effective Continuous Integration and Continuous Delivery, as it ensures that the integrated and delivered code is always of a releasable quality.

Creation and Evolution

The Development Team is primarily responsible for creating and maintaining the Definition of Done. If the organization already has a DoD for the product, the team must adhere to it. If not, the team creates one. This collaborative process ensures buy-in and a realistic set of criteria that the team can commit to. The Product Owner and stakeholders may provide input, especially regarding user-facing quality and business readiness, but the technical aspects are owned by the team.

The DoD is not immutable. It should be inspected and adapted regularly, typically during the Sprint Retrospective. As the team matures, gains new skills, or adopts new tools (e.g., automated testing frameworks, CI/CD pipelines), the DoD can and should evolve to reflect these improvements, aiming for higher quality and faster delivery. For instance, a team might initially have "Manual Regression Testing Complete" in their DoD, and later evolve it to "Automated Regression Tests Pass."

Application in the Workflow

The DoD is applied throughout the Sprint:

1. Sprint Planning: During Sprint Planning, the team considers the DoD when selecting Product Backlog Items. They must ensure they can realistically meet the DoD for all selected items within the Sprint. The DoD influences the effort estimation for each item.
2. During the Sprint: As the team works on Product Backlog Items, they continuously strive to meet all DoD criteria. This means integrating code, writing tests, performing code reviews, updating documentation, and deploying to relevant environments as part of the ongoing work, not as separate, post-development phases. The Daily Scrum is a good opportunity to discuss progress towards meeting the DoD for items.
3. Before Sprint Review: Only Product Backlog Items that fully meet the Definition of Done are considered "Done" and are eligible to be presented at the Sprint Review. If an item does not meet the DoD, it cannot be presented as "Done" and typically returns to the Product Backlog for future Sprints.

Typical Components of a Definition of Done

While the specific items in a DoD will vary by team, product, and technology stack, common categories include:

The DoD should be visible to everyone, often displayed as an Information Radiator on a physical or digital Kanban Board or team wiki.

Benefits

• Improved Product Quality: Consistently high standards lead to more robust and reliable software.
• Increased Predictability: Knowing what "Done" truly entails helps in more accurate forecasting and planning.
• Reduced Rework and Bugs: Quality activities are integrated throughout development, catching issues earlier.
• Enhanced Team Collaboration: A shared understanding fosters better communication and reduces internal conflicts over work completeness.
• Greater Stakeholder Trust: Stakeholders have confidence that "Done" work is truly ready and valuable.
• Empowered Self-Organizing Teams: The team owns the DoD, empowering them to define and commit to their quality standards.
• Facilitates Continuous Delivery: A strong DoD is essential for enabling frequent, reliable releases.

Limitations

• Can Be Challenging to Define: Especially for new teams or complex products, agreeing on a comprehensive DoD can take time.
• Requires Discipline: The team must consistently adhere to the DoD, even under pressure, which requires strong discipline.
• May Initially Slow Down Velocity: If a team was previously cutting corners, adopting a robust DoD might initially appear to slow down their output as they integrate more quality activities. This is a short-term trade-off for long-term quality.
• Risk of Becoming a Bureaucratic Checklist: If not regularly reviewed and adapted, the DoD can become a rigid, outdated checklist that hinders rather than helps.

Common Mistakes

• Vague or Ambiguous Criteria: Using terms like "mostly tested" or "some documentation" defeats the purpose of clarity.
• Not Owned by the Team: If the DoD is imposed by management or external parties, the team may not feel ownership or commitment.
• Confusing DoD with Acceptance Criteria: The DoD is universal; acceptance criteria are specific to a PBI.
• Ignoring the DoD: Rushing to declare items "Done" without meeting all criteria leads to technical debt and quality issues.
• Not Evolving the DoD: A static DoD fails to reflect team maturity, new tools, or changing product needs.
• Too Strict or Too Lenient: An overly strict DoD can paralyze a team, while a too-lenient one undermines quality.
• Not Visible: If the DoD isn't easily accessible and visible, it's easy for team members to forget or ignore.

Real-world Examples

Consider a software development team building a web application. Their Definition of Done might include:

• Code committed to version control.
• Code reviewed by at least one other developer and approved.
• All unit tests pass (100% pass rate).
• New unit tests written for new/changed code (e.g., >80% coverage for new code).
• Integration tests pass.
• Acceptance criteria for the Product Backlog Item are met and verified.
• Deployed to a staging environment.
• Performance tests executed for critical paths.
• Security scan passed with no critical vulnerabilities.
• Relevant documentation (e.g., API docs, user guide updates) completed.
• Product Owner has reviewed and accepted the functionality.

For a hardware team, the DoD might include "CAD design approved," "Prototype built," "Stress tests passed," or "Manufacturing specifications finalized."

Best Practices

• Collaborative Creation: The entire Development Team should create and own the DoD.
• Make it Visible: Display the DoD prominently (e.g., on a physical board, wiki, or digital tool) as an Information Radiator.
• Be Specific and Measurable: Use clear, unambiguous language. Quantify criteria where possible (e.g., "90% code coverage," "zero critical bugs").
• Regularly Inspect and Adapt: Review and update the DoD during Sprint Retrospectives to reflect learning, new tools, and evolving team capabilities.
• Start Simple, Then Grow: Don't try to create a perfect DoD on day one. Start with a basic set of essential criteria and expand it as the team matures.
• Integrate Quality Activities: Ensure that DoD criteria are integrated into the daily workflow, not treated as a separate phase at the end.
• Educate Stakeholders: Help stakeholders understand what the DoD means so they have realistic expectations about "Done" work.
• Consider Organizational DoD: If multiple teams work on the same product, a common organizational DoD can ensure consistency across teams, which individual teams then augment.