The Definition of Done (DoD) is the formal description of the state of the Increment when it meets all required quality criteria. Once a Product Backlog Item meets the DoD, it contributes to a usable, potentially releasable Increment. The DoD creates transparency about what “done” truly means and prevents misunderstandings between teams, Product Owners, and stakeholders.
The Scrum Guide specifies: when multiple Scrum Teams work on the same product, they must share a common DoD. Team-specific additions are allowed, but they cannot replace or undermine the product-level DoD.
Types of DoD – official vs. practice
- Product DoD (official, Scrum Guide)
The mandatory definition for the entire product. All teams working on the same product must comply.
Example: “All features integrated, regression tests green, operational documentation updated.”
- Team DoD (practical addition)
Teams may add stricter rules on top of the shared Product DoD.
Example: “Code coverage ≥ 80 %, all pull requests reviewed.”
- Organizational DoD (practical addition)
Company-wide baselines such as security, compliance, or architectural standards.
Example: “Security scans show no critical findings, GDPR/privacy checks performed.”
- Release/Deployment DoD (practical addition)
Defines what must be satisfied before an Increment can be released to production. Adds operational and deployment aspects.
Example: “Automated deployment via CI/CD, monitoring alerts tested, release notes written.”
Important: Official Scrum only defines the product-wide DoD. The other layers are practical extensions often needed in scaled or regulated environments.
Practical Relevance
- Transparency & quality: DoD makes non-negotiable quality standards explicit.
- Integration: A shared DoD across teams prevents “integration hell.”
- Predictability: Stakeholders know that every Increment has the same quality baseline.
- Automation: Modern organizations encode DoD criteria into CI/CD pipelines to ensure consistency.
- Compliance: In industries like Automotive, MedTech, or Finance, the DoD also acts as proof for audits.
Real-World Examples
Cloud SaaS (Team DoD):
- Code reviewed, unit tests ≥ 80 %, API documentation updated.
- Benefit: Consistency within the team, fewer rework cycles, more stable releases.
Automotive (Product DoD):
- All software integrated, hardware-in-the-loop tests passed, safety case updated.
- Benefit: Teams deliver compatible software, integration becomes predictable.
MedTech (Organizational DoD):
- Traceability from requirements to tests to risks complete, validation protocols signed off.
- Benefit: Audit readiness, compliance with GxP/ISO 13485.
Finance (Release/Deployment DoD):
- Automated deployment, monitoring in place, incident runbooks maintained.
- Benefit: Production systems remain stable, releases are predictable and auditable.
Data/ML Products (Team + Product DoD):
- Reproducible pipelines, data-quality gates passed, drift monitoring active.
- Benefit: Trust in ML products, reproducibility for auditors.
Implementation in Practice
- Workshops: Define DoD jointly, align with organizational policies.
- Automation: Encode as much of the DoD as possible into CI/CD pipelines (tests, scans, compliance checks).
- Evolve iteratively: DoD should grow stricter as teams and products mature (e.g., more tests, deeper security checks).
- Make transparent: Reflect DoD compliance during Sprint Reviews and through metrics.
Anti-Patterns
- “Done = code complete” – ignoring quality, tests, and operations.
- Multiple DoDs for teams working on the same product – explicitly forbidden in Scrum.
- Paper DoD without automation – no one lives it.
- Confusing DoD with Acceptance Criteria – leads to “false done.”
CALADE Perspective
We see the DoD as a multi-layered quality model:
- Product-wide DoD as the binding standard.
- Team-specific extensions for additional rigor.
- Organizational baselines for compliance and security.
- Release/Deployment DoD to connect development with market impact.
This turns the DoD from a static checklist into a living governance instrument for quality, trust, and business value.
Related Terms
- Acceptance Criteria – item-specific conditions of satisfaction.
- Definition of Ready (DoR) – preconditions for items being “ready for development.”
- Increment – the sum of all completed Product Backlog Items that meet the DoD.
- Built-in Quality (SAFe) – principle ensuring quality is part of the process, not inspected afterward.