Written by Agile36 · Updated 2024-12-19
What is Definition of Done?
Definition of Done (DoD) is a shared understanding of what it means for work to be complete, including all quality standards, testing requirements, and acceptance criteria that must be met before a user story or increment can be considered finished.
Every Scrum Master knows the frustration: developers claim a story is "done," but it lacks documentation, hasn't been tested, or doesn't meet basic quality standards. The Definition of Done eliminates this ambiguity by establishing clear, measurable criteria that every team member understands and follows.
In my experience training thousands of professionals at Agile36, teams without a solid DoD spend 40-60% more time in rework cycles. They're constantly revisiting "completed" work because quality wasn't built in from the start. A well-crafted Definition of Done becomes your team's quality gate, preventing technical debt and ensuring consistent deliverables.
Understanding Definition of Done in Practice
The Definition of Done serves as a contract between team members about quality standards. Unlike acceptance criteria, which are specific to individual user stories, the DoD applies universally to all work items within a team or organization.
A typical Definition of Done includes multiple layers of requirements. At the story level, it might specify that code must be peer-reviewed, unit tests must achieve 80% coverage, and the feature must pass user acceptance testing. At the increment level, it could require integration testing, performance benchmarks, and security scans.
The most effective DoDs I've seen in my consulting work are living documents that evolve with team maturity. New teams might start with basic requirements like "code compiles" and "passes existing tests." Mature teams often include sophisticated criteria like automated accessibility testing, performance profiling, and comprehensive documentation updates.
Consider a software development team's DoD: Code is peer-reviewed and merged, unit tests achieve minimum coverage thresholds, integration tests pass, security scanning shows no high-severity issues, documentation is updated, and the feature is deployed to staging environment. Each criterion is measurable and verifiable.
The Definition of Done also creates transparency for stakeholders. Product owners know exactly what they're receiving when a team claims work is complete. This shared understanding reduces friction and builds trust between business and development teams.
Teams should regularly inspect and adapt their Definition of Done during retrospectives. As technical capabilities improve and organizational standards evolve, the DoD should reflect these changes. What starts as a simple checklist becomes a sophisticated quality framework.
Key Points
• Shared Understanding: DoD creates common agreement on what "complete" means across all team members • Quality Gate: Acts as a filter preventing incomplete or substandard work from moving forward • Reduces Rework: Clear completion criteria eliminate back-and-forth about whether work is truly finished • Transparency Tool: Provides stakeholders visibility into what they receive when work is "done" • Living Document: Should evolve with team maturity and organizational standards • Universal Application: Applies to all work items, unlike acceptance criteria which are story-specific • Measurable Criteria: Each element should be objectively verifiable, not subjective interpretation
Related Concepts
| Term | Relationship to Definition of Done |
|---|---|
| Acceptance Criteria | Specific conditions for individual stories; DoD applies universally |
| Sprint Goal | DoD ensures all work contributing to sprint goal meets quality standards |
| Increment | DoD defines when an increment is potentially shippable |
| Technical Debt | Strong DoD prevents accumulation of technical debt |
| Retrospective | Regular forum for inspecting and adapting Definition of Done |
Frequently Asked Questions
What's the difference between Definition of Done and acceptance criteria? Acceptance criteria are specific to individual user stories and describe what the story should accomplish. Definition of Done applies to all work items and defines quality standards for completion. A story might meet its acceptance criteria but still not satisfy the Definition of Done if it lacks proper testing or documentation.
Who creates the Definition of Done? The development team creates and owns the Definition of Done, often with input from the Product Owner and Scrum Master. In larger organizations, there may be organizational standards that inform the team's DoD, but the team must be able to commit to delivering work that meets these standards.
How detailed should our Definition of Done be? Start simple and evolve over time. New teams might have 5-7 basic criteria, while mature teams could have 15-20 detailed requirements. The key is ensuring every item is measurable, achievable by the team, and adds real value to quality or stakeholder confidence.
Can we have different Definitions of Done for different types of work? While there should be one primary DoD for the team, you might have additional criteria for specific work types. For example, user-facing features might require additional accessibility testing, while API work might need different documentation standards. Keep it simple and avoid too many variations.
How often should we update our Definition of Done? Review your DoD during retrospectives and update it when team capabilities change or organizational standards evolve. Most teams I work with make minor adjustments quarterly and major revisions annually. The goal is continuous improvement while maintaining stability.
Explore all our certification courses →
