Definition of done

The Definition of Done (DoD) is a shared agreement among team members about what criteria must be met before any work item is considered complete. It's a quality checklist that ensures consistency - when something is "done," everyone agrees on what that means. Without a clear DoD, "done" becomes subjective, leading to rework, quality issues, and misaligned expectations.

Why it matters

"Done" is deceptively simple. A developer might consider code done when it compiles. A tester might not call it done until testing passes. A product manager might expect documentation. A security team might require a vulnerability scan. When each person holds a different definition, conflict and confusion follow.

The Definition of Done eliminates this ambiguity. By making explicit what done means, teams can plan accurately, stakeholders can trust completion claims, and quality becomes consistent rather than variable. It prevents the accumulation of invisible work - technical debt, missing tests, incomplete documentation - that eventually creates bigger problems.

For product managers, the DoD provides confidence that released work meets quality standards without requiring constant verification. When the team says something is done, the DoD guarantees what that includes.

What goes into a definition of done

A comprehensive DoD typically addresses multiple dimensions of completeness:

Code quality - Code reviewed, meets style guidelines, passes static analysis, no known bugs introduced.

Testing - Unit tests written and passing, integration tests passing, edge cases covered, no regression in existing tests.

Documentation - User documentation updated if needed, API documentation current, release notes drafted.

Security - Vulnerability scan passed, no exposed credentials, security review completed if required.

Performance - Meets performance criteria, no significant degradation from baseline, load tested if applicable.

Deployment - Deployed to staging environment, deployment scripts work correctly, rollback tested.

Acceptance - Product owner has reviewed, acceptance criteria met, demo completed.

The specific items depend on your context. A healthcare application might require compliance documentation. A consumer app might require accessibility testing. The DoD should reflect what "quality" means for your specific situation.

Definition of done vs. acceptance criteria

These concepts are related but distinct:

Acceptance Criteria are specific to individual work items. They describe the conditions that particular feature or story must meet. "User can reset password via email link" is acceptance criteria.

Definition of Done applies to all work items universally. It describes the standard conditions everything must meet regardless of specific functionality. "Code reviewed and tests passing" applies to every story, not just one.

Acceptance criteria vary by story. Definition of Done is consistent across stories. A work item is complete when it meets both its specific acceptance criteria and the universal Definition of Done.

Levels of done

Organizations sometimes maintain multiple DoD levels for different scopes:

Story-level DoD - What must be true for an individual story to be complete. Code written, tested, reviewed.

Sprint-level DoD - What must be true at the end of a sprint. Integration tested, documentation updated, demo-ready.

Release-level DoD - What must be true before shipping to production. Performance validated, security approved, launch checklist completed.

Different levels acknowledge that some activities make sense at different cadences. You don't need release approval for every story, but you do need code review.

Creating an effective definition of done

Several principles help craft a useful DoD:

Involve the whole team. The DoD should reflect shared agreement, not imposed requirements. When the team creates it together, they understand and commit to it.

Start achievable, evolve toward ideal. An aspirational DoD that the team can't actually meet breeds cynicism. Start with what's realistic, then raise the bar as practices improve.

Make it visible. Post the DoD where the team sees it daily. Reference it in reviews. Make it part of the workflow, not a document that exists somewhere.

Review and update regularly. As the team matures or context changes, update the DoD. What seemed ambitious six months ago might now be routine.

Keep it focused. A DoD with 50 items becomes a checklist nobody reads. Focus on criteria that actually matter for quality and completeness.

Common pitfalls

DoD inflation happens when well-meaning additions accumulate without pruning. Eventually the DoD becomes so heavy that teams either ignore it or slow to a crawl.

Inconsistent application occurs when some items get exceptions. "It's done except for the documentation" normalizes incomplete work. The DoD should be non-negotiable - otherwise it's not a definition.

Individual interpretation emerges when criteria are too vague. "Code is clean" means different things to different people. Specific, verifiable criteria work better than subjective assessments.

Waterfall in disguise happens when the DoD creates sequential handoffs - code to review to testing to documentation. A healthy DoD supports parallel work rather than mandating a rigid sequence.

Missing team buy-in undermines the whole concept. A DoD imposed by management without team input feels like bureaucracy rather than quality commitment. The team must own it.

When a team genuinely commits to a shared Definition of Done, quality becomes a habit rather than a heroic effort. Each completed item meets a known standard, stakeholders can trust "done" means done, and the accumulation of incomplete work stops silently undermining the product.