What is Definition of Done and why it matters
Definition of Done (DoD) is the team's quality contract: the checklist that determines if a user story is truly finished. Without DoD, 'done' is subjective: for a dev it means code pushed, for QA it means tested, for PO it means deployed. That ambiguity generates incomplete work that returns as bugs, rework and technical debt.
A solid DoD has three layers: 1) Technical standards (tests, code review, coverage), 2) Functional validation (QA, PO sign-off, acceptance criteria met), 3) Production readiness (docs, deployment checklist, monitoring). It's not an infinite wishlist; it's the non-negotiable minimum to consider something ready.
Common mistake: DoD too lax ('works on my machine') or too strict (requires 100% coverage even in trivial code). The balance: rigorous enough to maintain quality, pragmatic enough not to block progress.
Evolve DoD each retro: if production bugs reveal gaps (e.g., rollback not tested), add that item. If something never applies (e.g., 'legal review' on internal features), remove it or mark 'if applicable'.
How to implement DoD in your team from scratch
Step 1: 1-hour workshop. Gather dev, QA, PO, ops. Ask: 'What conditions must be met for me to trust this goes to prod without exploding?'. Each role contributes perspective: devs talk tests/refactoring, QA functional coverage, ops deployment/rollback, PO acceptance criteria.
Step 2: Group items into categories (dev, testing, docs, deployment, quality). Avoids flat 50-bullet lists nobody reads. Categories = manageable cognitive chunks.
Step 3: Prioritize must-haves vs nice-to-haves. A 40-item DoD where 30 are optional doesn't work. Define 10-15 non-negotiables (e.g., tests passing, code review, QA sign-off) and 5-10 conditionals (e.g., security review only if touching authn/authz).
Step 4: Make DoD visible. Put it in Jira/Linear as templated checklist on each ticket. In daily standup, dev says 'Feature ready, just missing DoD item 8: docs'. Makes progress transparent.
Step 5: Audit in retro. If a bug reached prod because a DoD step was missed, discuss if DoD was clear, was ignored, or lacks enforcement (e.g., CI should block merge if tests don't pass).
DoD for remote and async teams
Challenge: without in-person stand-ups, it's hard to validate DoD was met. Solution: automation + async accountability. Technical items (linter, tests, coverage) validated by CI: red pipeline = merge blocked. Human items (code review, QA) tracked by tool: PR doesn't merge until 2 approvals, ticket doesn't move to 'Done' until QA moved to 'Verified'.
Use checklists in PRs. Template in GitHub/GitLab: markdown with DoD checkboxes. Dev ticks what's met, reviewers validate. Example:
- [x] Unit tests passing - [x] Coverage > 80% - [ ] Docs updated - [x] QA sign-off
If something unchecked, PR not approved until completed or justified (comment: 'docs not applicable because internal fix').
For async items like 'PO review', use labels/tags in Jira: ticket has 'needs-po-review' label, PO filters by that 1-2 times/day, gives feedback, removes label. Avoids 'waiting for PO to log on' blocks.
Pro trick: DoD must be self-service. If an item requires tribal knowledge ('request access to X system'), document the how-to in DoD itself with link. E.g., 'Deploy to staging (see runbook)'.
Common mistakes and how to avoid them
Mistake 1: DoD changes every sprint. Creates confusion. DoD should be stable except deliberate changes in retro. If it changes 3 times per sprint, team doesn't internalize it.
Mistake 2: DoD is aspirational, not realistic. '100% coverage', 'zero tech debt' sound good but are unattainable. DoD should reflect what we can sustainably achieve, not utopia. Better '> 80% coverage in critical logic' than '100% always'.
Mistake 3: DoD is only technical. Missing product side: 'Does it meet acceptance criteria?', 'Did PO see it working?'. A technically perfect feature that doesn't solve user need isn't done.
Mistake 4: No enforcement. DoD lives in a Google Doc nobody reads. Solution: make it part of workflow (CI checks, PR templates, Jira automation that doesn't allow closing ticket without completing checklist).
Mistake 5: Identical DoD for all work types. A P0 prod hotfix can't have same DoD as new feature. Define DoD by type: hotfix (minimal: critical tests, rollback plan), feature (complete: tests, docs, QA, PO), tech spike (findings doc + architecture decision).
Guiding principle: DoD should be enabler, not blocker. If team sees it as bureaucracy, something's wrong. It should give confidence that what we deploy won't break production.