Definition of Done
The explicit checklist of quality criteria, testing, and documentation requirements that must be met before work is considered complete. It's the contract that makes velocity meaningful.
What is Definition of Done?
Definition of done (DoD) is a shared agreement about what “complete” actually means. It prevents work from being shipped half-finished, code from being reviewed incompletely, or features from lacking documentation. Without it, velocity metrics are meaningless—you can’t compare “28 points of loosely-reviewed code” to “28 points of production-ready features.”
A robust DoD includes: code complete and committed, tests written and passing, code review completed, documentation updated, acceptance criteria verified, and deployment-ready artifacts created. Some teams add staging deployment, security scan, or analytics instrumentation. The specifics vary by context, but the principle is universal: if it’s not on the DoD checklist, it’s not actually done.
Common DoD Elements
Technical elements: unit tests at 80%+ coverage, integration tests passing, no critical linting violations, no security vulnerabilities flagged by scanning tools. Human elements: code reviewed by at least one other engineer, product owner acceptance criteria verified, documentation written (code comments, user-facing docs, API specs). Operational elements: merged to main, staging deployment validated, feature flag structure prepared, rollback procedure documented.
Weak teams have fuzzy DoD: “code is done when it compiles” or “when the dev thinks it’s ready.” This invites the disaster of features shipping without tests, documentation, or operational preparation. Strong teams have DoD embedded in their tooling—pull requests can’t merge without test coverage, deployment pipelines gate on security scans.
DoD and Quality Tradeoffs
DoD sets a floor on quality, not a ceiling. A stricter DoD (e.g., 85% test coverage, security scanning, performance testing) creates better code but reduces velocity. A looser DoD (e.g., code compiles) speeds shipping but accumulates technical debt and defects.
Most teams should operate at 70-80% coverage, code review, and basic security scanning. Beyond that, returns diminish. A startup shipping MVP might use a leaner DoD; a healthcare company handling patient data needs stricter standards. The choice should be explicit and driven by risk tolerance and customer impact, not default.
Why It Matters for Product People
Definition of done is where engineering promises translate into user value. A feature marked “done” but lacking tests often generates defect reports two weeks later, derailing subsequent sprints. A feature without user documentation frustrates customers. By enforcing DoD, you protect the velocity metric that makes roadmap planning possible.
Use DoD as a forcing function for quality conversations. If your team consistently violates DoD (shipping without tests, without review), that’s a signal that the standard is either unrealistic or not valued culturally. Either adjust DoD or invest in the practices that enable it—but don’t ignore the violation.
Related Concepts
DoD connects to testing practices, code quality standards, and documentation culture. It also feeds velocity calculations—changing DoD mid-year breaks your forecasting model, so establish it at the beginning and only modify it deliberately with full transparency on impact to velocity.