Agile definition of done

The Definition of Done (DoD) is a shared understanding within an agile team of what "complete" means. It's a checklist of criteria-such as code review, testing, documentation-that must be satisfied before any piece of work can be called done. Without it, "done" becomes subjective, leading to inconsistent quality and work that comes back as bugs or technical debt.

Why it matters

"Done" is surprisingly ambiguous. A developer might consider code done when it compiles. A tester might consider it done when tests pass. A product manager might consider it done when it's deployed and customers can use it. These different interpretations cause problems when they collide.

The Definition of Done creates explicit shared expectations. When a team member says something is done, everyone knows exactly what that means. There's no 90% done, no "done but needs testing," no lingering work that surfaces later as surprises.

This consistency enables planning. If the team knows what done means, they can estimate how long it takes to get there. If done is a moving target, estimation becomes guesswork.

What to include

A Definition of Done typically addresses several areas:

Code quality criteria ensure the code meets team standards. This might include: code follows style guidelines, code has been reviewed by a peer, no new linting errors, complex logic is documented.

Testing criteria ensure the work is verified. This might include: unit tests written and passing, integration tests passing, edge cases covered, no regression in existing functionality.

Documentation criteria ensure knowledge is captured. This might include: README updated if needed, API documentation current, user-facing help content updated.

Deployment criteria ensure the work can be released. This might include: merged to main branch, deployed to staging, smoke tests passing, feature flags configured.

The specific items depend on your context. A regulated industry might require compliance review. A consumer product might require accessibility verification. Include what matters for your situation.

Definition of done vs. acceptance criteria

These are related but different:

Acceptance criteria are specific to one user story or feature. They define what this particular work must accomplish. "Users can reset password via email" is an acceptance criterion for the password reset story.

Definition of Done applies to all work. It defines standards that every piece of work must meet regardless of what it does. "Code has been reviewed" applies to every story, not just some.

Both must be satisfied for work to be complete. The criteria define the what; the Definition of Done ensures the how meets quality standards.

Creating your definition of done

Start with what actually needs to happen for work to reach production safely. Be realistic-if your team can't consistently meet a criterion, don't include it yet.

Involve everyone who touches the work. Developers know the technical quality criteria. QA knows testing requirements. Design knows UX standards. Ops knows deployment needs. Each perspective contributes to a complete definition.

Keep it achievable. Every criterion must be completable within a sprint. If comprehensive security review takes three weeks, it can't be in the sprint-level Definition of Done.

Make it visible. Post it where the team sees it daily. Reference it in planning and review. It should be a living presence, not a document that gets filed away.

Evolving the definition of done

The Definition of Done should strengthen over time as the team matures:

Signs you should strengthen it: Bugs discovered shortly after "completion." Work frequently reopened. Quality inconsistent between team members. Technical debt growing faster than expected.

Signs it's too ambitious: Team never completes sprint commitments. Items frequently stuck waiting for DoD activities. Team routinely skips items due to time pressure.

Review the Definition of Done in retrospectives. Is it serving the team? What should be added? What isn't providing value? Like everything in agile, it should adapt based on experience.

Common mistakes

Too long definitions become checklists that no one reads. Focus on what genuinely matters for quality. If an item rarely catches problems, consider removing it.

Too vague items like "code is good" don't provide guidance. Be specific enough that completion is unambiguous.

Optional treatment defeats the purpose. If the DoD is treated as a guideline rather than a requirement, it provides no value. The team must commit to actually meeting it.

Not connected to reality happens when the DoD describes aspirational practice rather than what actually happens. Start with where you are and improve from there.

Never revisited definitions become stale. The team changes, the product changes, the technology changes. The Definition of Done should evolve too.

Definition of done and quality

The Definition of Done is fundamentally about quality. It encodes the team's agreement about what quality means and makes that agreement visible and enforceable.

This isn't overhead-it's investment. Work that meets the Definition of Done is more likely to stay done. Skipping quality steps to save time usually costs more time later in bugs, rework, and technical debt.

Teams that take their Definition of Done seriously build quality into their process rather than trying to inspect it in at the end.