Definition of Done and Quality: Making “Done” Unambiguous

What the Definition of Done (DoD) Is (and What It Is Not)

The Definition of Done (DoD) is a shared, explicit checklist of quality criteria that must be true for any work item to be considered Done. It makes “Done” unambiguous by turning quality expectations into observable conditions rather than opinions.

DoD is:

• A quality gate for the Increment: it protects the product from partially finished work being treated as releasable.
• Shared by the whole team: everyone uses the same bar for completion, regardless of who did the work.
• Applied consistently: if one item must meet it, all items must meet it.

DoD is not:

• A task list for how to do the work (that belongs in the team’s working agreements or engineering practices).
• A per-item “definition” that changes to make a hard item pass. If you change the DoD, you change it for everyone and for future work.
• A promise of business value. DoD is about quality and completeness, not whether the feature was the right one.

Why DoD Protects the Increment

Without a DoD, teams often accumulate hidden work: untested code, missing documentation, incomplete security checks, or unreviewed changes. This creates “inventory” that looks finished but is risky and expensive to complete later. A strong DoD prevents last-minute testing and handoffs by requiring quality activities to happen as part of completing each item.

Think of the DoD as the minimum set of conditions that keep the product in a healthy, releasable state. If the team can’t meet the DoD within the Sprint, the work isn’t Done—no matter how close it feels.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Examples of DoD Criteria (Tailored to Different Products)

A good DoD is specific enough to verify and broad enough to cover the product’s real risks. Below are example criteria you can adapt. The goal is not to copy-paste all of them, but to choose the ones that match your product and maturity.

Common DoD Criteria for Software Products

• Code quality: code follows agreed standards; no critical static analysis issues; no debug flags left on.
• Peer review: changes reviewed by at least one other developer; review comments addressed; no “rubber-stamp” reviews.
• Automated tests: unit tests added/updated; tests pass in CI; coverage meets agreed threshold for changed areas.
• Integration: merged to main branch; no failing builds; feature flags used where appropriate.
• Functional verification: acceptance criteria verified; exploratory testing performed for risky areas.
• Documentation: user-facing help updated if behavior changed; internal docs updated for new endpoints/configuration.
• Security: dependency scan run; no high/critical vulnerabilities introduced; secrets not committed; basic threat considerations checked.
• Performance: no regression against agreed benchmarks for impacted flows; profiling done when needed.
• Observability: logs/metrics/traces updated for new behavior; alerts not broken; dashboards updated if required.
• Accessibility: UI changes meet agreed accessibility checks (e.g., keyboard navigation, contrast, labels).

DoD Criteria for Mobile Apps

• Tested on agreed device/OS matrix (or emulator set) for impacted screens.
• App permissions reviewed; no new permission without justification.
• Offline/poor-network behavior checked for impacted flows.
• Crash reporting events validated for new code paths.
• Store metadata or release notes updated when required.

DoD Criteria for Data/Analytics Products

• Data quality checks added/updated (null rates, freshness, schema validation).
• Backfill/migration plan executed or documented.
• Dashboards validated against source-of-truth queries.
• Access controls verified; sensitive fields handled correctly.
• Lineage/documentation updated so others can trust and reuse the dataset.

DoD Criteria for Infrastructure / Platform Work

• Infrastructure-as-code reviewed and merged; plan/apply verified in non-prod.
• Rollback strategy documented and tested where feasible.
• Monitoring and alerting configured for new components.
• Security hardening checks applied (least privilege, network rules, secrets management).
• Runbook updated for on-call support.

DoD Criteria for Non-Software Products (Examples)

DoD is not limited to code. It can apply to marketing assets, training materials, or operational processes as long as criteria are verifiable.

• Marketing campaign asset: copy reviewed; legal approval obtained; links verified; tracking configured; accessibility checks for images/video captions.
• Training module: content reviewed by subject expert; exercises validated; audio quality checked; published in the correct location; version noted.
• Operational process change: SOP updated; stakeholders trained; audit/compliance checks passed; metrics defined to detect issues.

How to Write a DoD That Is Verifiable

Ambiguous DoD statements create arguments. Verifiable statements create alignment. Prefer criteria that can be checked quickly and consistently.

Practical Step-by-Step: Creating or Tightening Your DoD

1. List your top quality risks (e.g., regressions, security issues, unclear usage, operational failures).
2. Translate each risk into a check that can be performed per item (e.g., “CI passes,” “threat check for new endpoints,” “runbook updated”).
3. Start with a minimum DoD you can meet consistently today. Consistency beats ambition.
4. Add “how to verify” notes for any criterion that could be interpreted differently (e.g., what counts as “tested”).
5. Make it visible: keep it in a shared place and reference it during work, not only at the end.
6. Inspect failures: when something slips, decide whether to improve the DoD, improve practices, or both.

How the DoD Changes Over Time (Without Becoming Chaos)

DoD should evolve as the team’s capabilities and product risks evolve. Early on, a team might not have full automation or mature security tooling. Over time, the DoD typically becomes stricter as the team invests in enabling practices (CI, test automation, scanning, observability).

Good Reasons to Update the DoD

• Recurring defects indicate a missing quality check (e.g., regressions → add automated tests for changed areas).
• New regulatory or security requirements (e.g., add vulnerability scanning, logging requirements).
• Product scale changes (e.g., performance checks become necessary).
• Operational pain (e.g., incidents → add monitoring/runbook updates to DoD).

Practical Step-by-Step: Evolving DoD Safely

1. Propose a change with a clear trigger: “We had 3 production incidents due to missing alerts; add ‘alerts configured for new services.’”
2. Define the smallest enforceable version: start with “alerts exist for critical errors,” then expand later.
3. Set an effective date: apply to new work from a specific point to avoid confusion.
4. Invest in enablement: if the DoD adds a check, ensure tooling/time exists (e.g., CI pipeline, templates, scripts).
5. Audit adoption: spot-check a few items each Sprint to ensure the new DoD is actually being met.

A common anti-pattern is raising the DoD without providing the means to meet it, which leads to “checkbox compliance” or hidden work. Treat DoD improvements as product-quality investments.

How to Handle Items That Don’t Meet the DoD

If an item does not meet the DoD, it is not Done. The team should avoid “almost done” categories that blur reality. Instead, handle it transparently so planning and quality remain trustworthy.

Practical Step-by-Step: When Work Is Not Done

1. Identify the unmet criteria: be explicit (e.g., “peer review missing,” “security scan not run,” “docs not updated”).
2. Decide the next action based on impact and feasibility:
   • Finish it properly as soon as possible (preferred when small and within capacity).
   • Split the work so the Done portion can stand alone and the remaining work becomes a new item (only if the Done portion still meets DoD and is coherent).
   • Rework the approach if the current implementation can’t meet DoD without major changes.
3. Make remaining work visible: create a new backlog item for the unfinished portion with clear acceptance criteria and the same DoD.
4. Do not “carry over” silently: unfinished work should not be treated as completed progress.
5. Learn the cause: was it underestimated effort, missing skills, missing tooling, or unclear DoD?

What About “Done Except Testing”?

“Done except testing” is a signal that testing is being treated as a phase or a handoff. If testing is required by the DoD, then the item is simply not Done. The corrective action is to change how work is sliced and executed so testing happens continuously, not at the end.

Common Traps and How to Correct Them

Trap: “Done but Not Tested”

What it looks like: coding finishes, but verification is deferred; bugs pile up; the end of the Sprint becomes a test crunch.

Corrections:

• Make testing explicit in the DoD (automated + functional verification).
• Slice work thinner so each item can be tested quickly (e.g., one workflow step at a time).
• Shift testing left: write tests alongside code; run CI frequently; use test data and environments that are ready early.
• Limit work in progress so people finish and verify before starting new items.

Trap: “Done in Dev Only”

What it looks like: changes exist on a developer machine or a feature branch, but not integrated; integration happens late and causes conflicts.

Corrections:

• Require integration in the DoD: merged to main; build green; deployable artifact produced.
• Use short-lived branches and frequent merges.
• Adopt feature flags so incomplete functionality can be integrated safely without being exposed.

Trap: “Reviewed Later” or “We’ll Document After Release”

What it looks like: review and documentation become a backlog of chores; knowledge stays in heads; support load increases.

Corrections:

• Include review and documentation in DoD with clear scope (what must be updated when behavior changes).
• Use templates (PR checklist, doc checklist, runbook skeleton) to reduce effort.
• Define “documentation triggers”: e.g., “If a user-visible behavior changes, update user docs; if an API changes, update API docs.”

Trap: “Security Is Someone Else’s Job”

What it looks like: security checks happen only during audits or late reviews; vulnerabilities appear after integration.

Corrections:

• Add lightweight security checks to DoD (dependency scan, secrets scan, access control verification).
• Automate what you can in CI so checks are routine rather than heroic.
• Define when deeper review is needed: e.g., “New authentication flow requires threat modeling session.”

Trap: DoD Becomes a Checkbox Ritual

What it looks like: people mark criteria as done without real verification; quality still suffers.

Corrections:

• Make criteria evidence-based: link to test results, scans, review approvals, updated docs.
• Random audits: occasionally pick an item and verify each DoD criterion together.
• Keep DoD lean: remove items that don’t reduce risk or aren’t enforceable.

Making “Done” Unambiguous in Daily Work

DoD works best when it is used continuously, not checked only at the end. Teams often operationalize it with a simple checklist attached to each work item or pull request.

Example per-item DoD checklist (software)  [ ] Acceptance criteria verified  [ ] Peer review completed  [ ] Automated tests added/updated and passing in CI  [ ] Merged to main; build green  [ ] Security scan clean (no high/critical)  [ ] Docs updated (user/API/runbook as applicable)

When everyone uses the same checklist and treats unmet criteria as “not Done,” quality stops being a last-minute phase and becomes part of completing each piece of work.