Definition
A Definition of Done (DoD) is a shared, explicit set of conditions that a work item must satisfy before a team considers it complete. In software and product engineering, it establishes a common quality boundary across implementation, review, testing, documentation, security, and release readiness.
It prevents different contributors from using “done” to mean different things, such as code written, code merged, tests passed, or behavior verified. A useful DoD describes observable outcomes and evidence, not vague intentions.
It can include peer review, appropriate automated tests, security checks, accessibility verification where relevant, updated documentation, and no unresolved critical defects. Requirements may vary by risk, but conditional checks should be clear.
The DoD must remain practical and should not become a ceremonial checklist that people tick without evidence.
The boundary and limitations matter as much as the headline benefit. A team should know which responsibility the concept owns, which adjacent requirements still need separate controls, and what assumptions must remain true.
Its effectiveness depends on system criticality, dependencies, data quality, ownership, monitoring, and the ability to recover when expected behavior fails.
In practical use, the concept should be specific enough to guide a design or operating decision rather than simply describe an aspiration. State the relevant scope, assumptions, limitations, and the conditions under which it is expected to work.
Explain what evidence would show that it is functioning as intended and what signal would trigger review. This precision makes the document useful during onboarding, implementation, incident analysis, and later architecture changes.
Key Takeaways
The concept should be connected to a specific engineering outcome, a clear boundary, and evidence of success. Teams should state the problem, what remains outside scope, and what should happen when assumptions fail.
Ownership is part of the design: someone must maintain implementation, documentation, automation, and exceptions. Review the decision when risk, architecture, scale, or team structure changes.
Define the expected result in observable terms and identify who will maintain the approach after launch. If success cannot be measured or ownership is unclear, the implementation is not ready for broad adoption.
A team should also consider the full lifecycle: adoption, ongoing maintenance, upgrades, exception handling, and eventual retirement. The initial implementation cost is only part of the decision. Hidden costs can include additional dependencies, training, monitoring, testing combinations, and coordination between owners.
Make those costs visible when comparing options, and revisit the choice if actual operational experience differs from the original assumptions.
How It Works
Teams check each work item against the agreed conditions before marking it complete. Evidence can include test results, review approval, documentation changes, security scans, or verification in a representative environment. The DoD is a team-level baseline; acceptance criteria describe feature-specific behavior, while a Definition of Ready concerns whether work is sufficiently clear to begin.
Start by examining recurring defects and handoff gaps, agree on verifiable criteria, automate repeatable checks, and review the standard periodically. Keep it visible, proportionate to risk, and useful for improving quality rather than blaming individuals.
A robust workflow defines normal behavior, exceptional behavior, inputs, outputs, dependencies, ownership, and recovery. Include missing inputs, stale state, partial failure, unavailable dependencies, and concurrent operations. Instrument the process so operators can explain what happened and which action is safe. Test representative conditions before broad rollout.
The workflow should make failure behavior as explicit as normal behavior. Decide what happens if a dependency times out, data is incomplete, a configuration value is absent, or an operation only partially succeeds.
Define whether retries are safe, how duplicate work is recognized, and how operators can distinguish a transient issue from a persistent fault. Where decisions affect users or production state, preserve enough traceability to explain the outcome without collecting unnecessary sensitive information.
Compared to Related Concepts
Teams check each work item against the agreed conditions before marking it complete. Evidence can include test results, review approval, documentation changes, security scans, or verification in a representative environment. The DoD is a team-level baseline; acceptance criteria describe feature-specific behavior, while a Definition of Ready concerns whether work is sufficiently clear to begin.
Start by examining recurring defects and handoff gaps, agree on verifiable criteria, automate repeatable checks, and review the standard periodically. Keep it visible, proportionate to risk, and useful for improving quality rather than blaming individuals.
Related practices may work at different layers: one organizes information, another controls runtime behavior, and another measures outcomes. Compare them by responsibility, failure modes, dependencies, reversibility, and lifecycle cost. When multiple mechanisms are required, document how they interact and which is authoritative.
Similar-looking approaches can have different trust boundaries and responsibilities. Ask who makes the decision, who enforces it, where evidence is recorded, and who responds when something goes wrong. Two mechanisms may both be necessary, but they should not silently duplicate responsibility or leave a gap between teams.
Document the interaction and source of truth so future maintainers do not infer guarantees that were never provided.
Where It Fits and Where It Does Not
The approach is valuable when it resolves recurring friction or material risk. It may be excessive when a simpler practice already meets the need. Extra layers introduce configuration, maintenance, coordination, and failure modes, so benefits should justify lifecycle cost. Consider criticality, operational maturity, and the consequences of failure.
Use a level of rigor proportional to the risk. A prototype and a critical production workflow may require different safeguards; avoid both overengineering low-risk work and under-specifying high-impact behavior.
Consider the frequency of the problem, the cost of failure, and the maturity of the surrounding engineering process. A control may be justified for a high-volume or regulated workflow but excessive for a small, low-risk tool.
Conversely, an apparently simple use case can require stronger safeguards when it touches sensitive information or triggers irreversible actions. Let evidence and risk determine the level of rigor rather than adopting complexity by default.
Implementation and Practical Examples
Teams check each work item against the agreed conditions before marking it complete. Evidence can include test results, review approval, documentation changes, security scans, or verification in a representative environment. The DoD is a team-level baseline; acceptance criteria describe feature-specific behavior, while a Definition of Ready concerns whether work is sufficiently clear to begin.
Start by examining recurring defects and handoff gaps, agree on verifiable criteria, automate repeatable checks, and review the standard periodically. Keep it visible, proportionate to risk, and useful for improving quality rather than blaming individuals.
Start with a bounded use case. Record the problem, affected systems and teams, baseline, success criteria, prerequisites, rollout plan, and recovery path. Keep the first change small enough to validate. After rollout, compare results with the baseline and review incidents, rework, latency, cost, maintainability, and feedback.
Define acceptance evidence, the owner who can pause or reverse rollout, and how lessons will be recorded for the next iteration.
Validation should include normal operation, invalid inputs, boundary values, failure and recovery, and integrations likely to change. Define measurable acceptance criteria and decide who can pause, roll back, or disable the implementation.
For cross-team work, document compatibility expectations, migration steps, support ownership, and any retirement date for old behavior. Collect evidence during a pilot and use it to improve the design before expanding to more systems.
Best Practices
Teams check each work item against the agreed conditions before marking it complete. Evidence can include test results, review approval, documentation changes, security scans, or verification in a representative environment. The DoD is a team-level baseline; acceptance criteria describe feature-specific behavior, while a Definition of Ready concerns whether work is sufficiently clear to begin.
Start by examining recurring defects and handoff gaps, agree on verifiable criteria, automate repeatable checks, and review the standard periodically. Keep it visible, proportionate to risk, and useful for improving quality rather than blaming individuals.
Keep ownership explicit and documentation close to the workflow. Prefer clear interfaces, safe defaults, reliable automated checks, useful errors, and reversible changes. Test failure and recovery behavior, not only the happy path.
Track quality and reliability alongside speed or adoption, review exceptions, and remove obsolete artifacts. Use consistent naming, test edge cases, keep evidence useful but privacy-aware, and revisit the design after meaningful incidents or system changes.
Keep the implementation observable and maintainable. Use consistent naming, explicit ownership, version-controlled configuration where appropriate, and documentation near the point of use. Automate repeatable checks but test the automation itself. Monitor for unintended side effects such as higher latency, increased resource use, support burden, or new failure modes.
Review stale settings and exceptions periodically, and keep the recovery path documented and tested.
Common Misconceptions and FAQs
Teams check each work item against the agreed conditions before marking it complete. Evidence can include test results, review approval, documentation changes, security scans, or verification in a representative environment. The DoD is a team-level baseline; acceptance criteria describe feature-specific behavior, while a Definition of Ready concerns whether work is sufficiently clear to begin.
Start by examining recurring defects and handoff gaps, agree on verifiable criteria, automate repeatable checks, and review the standard periodically. Keep it visible, proportionate to risk, and useful for improving quality rather than blaming individuals.
A tool, pattern, metric, or document does not guarantee an outcome; results depend on scope, implementation, evidence, and ownership. How should a team start? Define the problem and test a bounded use case.
How should success be measured? Choose observable outcomes and review them over time. When should the approach change? When requirements, scale, dependencies, or evidence changes.
Another mistake is to treat adoption or checklist completion as proof of success. These show activity, but the real question is whether the intended quality, reliability, safety, speed, or clarity improved. Teams should adjust or retire an approach when evidence shows that its cost exceeds its benefit.
Keep decisions proportionate to risk, record meaningful exceptions, and ensure that the people who build and operate the system can explain its purpose and failure response.
