Definition of Done (DoD)

Status: Complete
Category: Delivery
Default enforcement: Hard
Author: PushBackLog team

Tags

• Topic: delivery, quality
• Methodology: Agile, Scrum
• Skillset: any
• Technology: generic
• Stage: execution, review, deployment

Summary

The Definition of Done (DoD) is a shared, explicit, and visible agreement on the criteria that every work item must satisfy before it can be called complete and counted as delivered. It is a quality contract — not a checklist to be selectively applied. Work that hasn’t met the DoD is not done; it is undone work that will eventually have to be paid for, typically at a significantly higher cost.

Rationale

What “done” actually means

Without an explicit DoD, “done” defaults to whatever each individual means by it at the moment they’re asked. A developer means the code compiles and the happy path runs. A product owner means the feature can be shown at the demo. A QA engineer means it’s been tested. An ops engineer means it’s deployed. These definitions are incompatible — and the gaps between them become technical debt, support incidents, and missed deliveries.

The DoD closes that gap by making the full definition of “releasable” explicit and shared before work begins. It answers, once for the whole team: what does it take to ship this?

Technical debt is undone work made visible

Every item that ships without meeting the full DoD leaves behind technical debt — work that was deferred, not eliminated. This debt has compounding interest: undocumented code becomes harder to modify; untested code produces regressions; undeployed-to-staging code fails in production. A team that consistently skips DoD criteria under deadline pressure accumulates a quality deficit that eventually manifests as a slowdown in delivery speed. The DoD is the safeguard that prevents the team from borrowing against its own future velocity.

The DoD as a transparency tool

Beyond quality, the DoD creates transparency. When everyone knows what “done” means, the whole team — including stakeholders — can accurately assess progress. Without it, sprint velocity is meaningless: a sprint that “completed” ten stories where four of them have no tests and two have no documentation has not completed ten production-quality stories. It has completed six and taken shortcuts on four.

The AI delivery multiplier

As teams delegate implementation to AI pair programmers or autonomous agents, the DoD becomes the gate that separates “generated” from “shipped”. An AI can produce functionally correct code quickly. It will not, without explicit instruction, ensure tests are written, accessibility checked, documentation updated, or a feature flag configured. The DoD codified in the backlog system makes these requirements machine-enforceable, not reliant on human memory at review time.

Guidance

The three dimensions of a DoD

A complete DoD covers three distinct dimensions:

A DoD that covers only functional criteria will accumulate quality and non-functional debt silently.

Constructing your DoD

The DoD should be:

• Co-created by the whole team — not imposed by a manager or written by one person
• Visible — posted somewhere the team sees it regularly, not buried in a wiki page
• Versioned — reviewed and evolved periodically (retrospectives are a natural moment)
• Enforceable — items that don’t meet it are not accepted as done at sprint review

Start lean. A DoD that the team can actually apply consistently is more valuable than an aspirational one that gets quietly ignored. Add criteria when the team is ready to hold them.

Levels of DoD

Non-functional requirements often sit at the sprint or release level rather than per-story — but they must appear somewhere visible, or they will be skipped.

When to apply it

Apply the DoD at the end of every work item, before it transitions to “done” in your backlog tool. At sprint review, the only items presented as complete are those that satisfy the DoD. Anything else is returned to the backlog as incomplete — no partial credit.

Examples

Example — Software team DoD (story-level)

Definition of Done — Engineering

[ ] Acceptance criteria verified by the person who wrote them (not the implementer)
[ ] All new and modified code reviewed by at least one other engineer
[ ] Unit tests written for new logic; no existing tests broken
[ ] Integration tests updated or added where applicable
[ ] CI pipeline passes (lint, test, build)
[ ] No new known security vulnerabilities introduced (checked via dependency scanner)
[ ] Feature flag configured if applicable
[ ] Deployed to staging environment and smoke-tested
[ ] Relevant documentation updated (API docs, README, internal wiki)
[ ] No increase in accessibility violations (checked via axe or equivalent)

Example — Additional sprint-level criteria

Definition of Done — Sprint Increment

[ ] All story-level DoD criteria met for every item in the sprint
[ ] Integrated increment has been smoke-tested end-to-end on staging
[ ] Any database migrations successfully applied to staging
[ ] Performance benchmark has not regressed vs. previous sprint baseline
[ ] Sprint review demo prepared

Example — DoD evolution over time

Anti-patterns

1. “80% done” counts as done

There is no partial credit in a DoD. A story that has code reviewed and tested but not deployed to staging is not done; it is 80% of the work required to be done. Counting it as done at sprint review inflates velocity and hides real progress.

2. Skipping the DoD under deadline pressure

“We’ll add the tests next sprint” is how technical debt starts. The DoD exists precisely for moments when doing things properly feels costly. If the team routinely skips DoD criteria under pressure, either the criteria are wrong (the team should update them) or the sprint plan is wrong (the team should push back on scope). Silently skipping is never the right answer.

3. The DoD lives in a document nobody reads

A DoD that isn’t visible doesn’t exist in practice. It needs to be integrated into the team’s workflow — whether as a checklist in your issue tracker, a pinned message in your team channel, or a physical checklist on the wall. Out of sight means out of mind.

4. The DoD never evolves

A DoD written in sprint 1 should look different in sprint 20. Quality practices mature, tooling improves, and new non-functional requirements emerge. A team that reviews its DoD quarterly and adjusts it based on what they’ve learned is doing it right. A team with the same DoD it wrote two years ago is either remarkably consistent or has stopped thinking about it.

5. DoD and acceptance criteria conflated

Acceptance criteria are the specific conditions for this story. The DoD is the universal quality bar for all stories. Confusing the two leads to stories with 40-item AC lists that include “code reviewed” and “tests passing” — criteria that shouldn’t need to be written per story because they’re already in the DoD.

6. DoD written by one person, not the team

A DoD imposed from above will not be owned by the team and will be treated as bureaucracy. The DoD must be a genuinely shared agreement — written together, understood by everyone, and updated through consensus. The act of building the list together is part of its power.

Related practices

• Definition of Ready
• Acceptance Criteria Quality
• Test-Driven Development
• Story Sizing

Part of the PushBackLog Best Practices Library. Suggest improvements →