Definition of Done

What is a Definition of Done?

A Definition of Done (DoD) is a shared agreement that states the exact conditions a product increment must meet to be considered complete. The Scrum Guide (2020) lists the DoD as a commitment for the Increment, making it the quality bar that every backlog item must reach before it can be released or demonstrated.

The term was first coined by Alistair Cockburn in his book Agile Software Development in 2001. The DoD is a way to ensure that all stakeholders have a shared understanding of what is expected from a user story and that all tasks associated with it have been completed. It is also a way to ensure that the user story is of high quality and meets the requirements of the customer

Definition of Done vs Acceptance Criteria

• Acceptance criteria describe feature‐specific behaviour (e.g., “When the user enters an invalid email, show an error message”).
• DoD describes global quality requirements (e.g., “Code reviewed, unit tests passing, documentation updated”).

Both are needed; the DoD ensures consistency, while acceptance criteria confirm functional intent.

Why your team needs a shared Definition of Done

When teams hold different mental models of what “done” means, velocity metrics become unreliable and release dates slip. A single, explicit Definition of Done brings engineers, testers, designers, and product stakeholders into alignment and prevents invisible work from leaking into future sprints.

Key benefits of a shared DoD

1. Transparency — Every backlog item passes the same checkpoints, turning sprint charts and progress demos into truthful indicators of readiness.
2. Predictability — Because hidden clean‑up tasks (tests, docs, security scans) are baked into each story, velocity stabilises and forecasting improves.
3. Built‑in quality — Defects, vulnerabilities, and documentation gaps are caught upstream, reducing incident costs and customer churn.
4. Faster onboarding — New hires grasp expectations quickly by reading the DoD rather than deciphering tribal knowledge.

Over time a well‑adopted DoD becomes both a social contract and a quality gate. If burndown stalls or incident counts spike, inspecting which DoD checkpoints were skipped often reveals the root cause.

Creating a Definition of Done

Crafting a DoD is a collaborative exercise: it must be rigorous enough to protect quality yet lean enough to fit inside a sprint cadence. Set aside a focused workshop so the whole team can debate trade‑offs and agree on realistic guardrails.

Creating a DoD in a workshop setting

A fruitful Definition‑of‑Done workshop balances divergence—surfacing pain points and quality ideas—with convergence—agreeing on a short, testable checklist. Use the guide below to facilitate a 90‑minute session for a team of six to ten people. Adjust timings for larger groups.

Preparation (the day before)

• Collect sprint metrics: escaped defects, incident count, cycle time, and any notable customer complaints.
• Ask participants to skim the latest production‑incident post‑mortems.
• Print or share a digital canvas with three columns: Goals, Pains, Potential DoD items.

Agenda (90 minutes total)

Facilitator tips

• Keep a parking lot for off‑topic discussions; return only if time allows.
• Use a timer to stay on schedule; unfinished items become action items, not meeting overruns.
• Capture the draft DoD in the team’s tooling (Jira definition, README section) before energy fades.

Running a structured agenda rooted in real pains ensures the resulting DoD is both aspirational and achievable.

What are examples of what goes into a DoD?

Typical examples of what teams put into a Definition of Done:

• Code reviewed and merged to the main branch.
• All unit tests and integration tests passing in CI.
• New code covered by at least 80 % unit tests.
• No critical SonarQube issues.
• Documentation updated (README, API docs).
• Feature flag toggled off by default.
• Security scan shows no high‑severity vulnerabilities.
• Product owner signs off in staging.

Although every DoD is context‑specific, these items recur because they protect the fundamentals: code quality, operational safety, and user value. Treat them as a starting point, then add or remove gates to match your domain.

Resist the urge to gold‑plate

Resist the urge to gold‑plate. A bloated DoD slows delivery and encourages bypasses. Review it quarterly; if a checkpoint no longer adds value or can be automated, simplify.

A living DoD adapts to new risks, compliance rules, or tooling. For example, the EU AI Act introduces audit requirements that many teams now add to their DoD (e.g., “Model cards published, bias tests run”). Version each change and communicate it in sprint planning so no one is surprised by a higher bar.

Definition of Done in a Scrum setting

A well‑crafted Definition of Done becomes the quality thread that weaves through every Scrum ceremony. Without it, progress discussions default to vague status talk; with it, each event has a built‑in yardstick for whether work is truly “potentially shippable.”

• Sprint Planning – The team selects backlog items only if they believe each can meet the DoD within the sprint. If an item seems risky, they split the story or expand their definition of tasks.
• Daily Scrum – Developers synchronise not just on feature progress but on DoD checkpoints (tests written, security scan queued, docs drafted). This keeps hidden tasks visible.
• Sprint Review – Stakeholders see increments that already satisfy the DoD, avoiding the “demo surprise” where a feature looks ready but lacks hardening.
• Sprint Retrospective – The team inspects where DoD items were skipped or proved too burdensome and adapts either the checklist or their engineering practices.

Because the DoD plays a defined role in each event, it acts like an ever‑present safety net: large enough to catch quality lapses, lightweight enough not to tangle the team’s momentum.

Definition of Done examples

Below is a comparative snapshot of how different teams tailor their DoD to domain constraints and workflow styles. Use the table as inspiration rather than prescription; your context will dictate which gates matter most.

Across these examples, the language stays binary and observable—critical traits that prevent subjective debates at the end of an iteration. Your DoD should evolve similarly: start lean, then add or remove checkpoints as risks, tooling, and compliance demands change.

Frequently Asked Questions

What is DoR and DoD in Agile?

“DoR” stands for Definition of Ready—the checklist that tells a team a backlog item is clear enough to start—while “DoD” is the Definition of Done, the checklist that confirms the item is complete and potentially shippable. Ready guards the input of a sprint; Done guards the output.

Is a Definition of Done mandatory in Scrum?

Yes. The Scrum Guide (2020) lists the Definition of Done as a commitment for the Increment, making it a required element of the framework. Teams may start with a lightweight DoD, but they cannot ignore it entirely without breaking Scrum rules.

What is the Definition of Done in PMP (Project Management Professional)?

In PMP terminology the DoD maps to the Acceptance Criteria defined in the project’s scope-baseline documents. It specifies conditions for deliverable acceptance and quality, ensuring stakeholder sign-off aligns with the project’s quality-management plan.

Who defines “Done” in Agile?

The entire agile team collaborates to define “Done,” but the Product Owner ensures it reflects customer and business needs, while developers and testers define the technical gates that guarantee quality. The Scrum Master (or agile coach) facilitates the conversation and promotes adherence.

What is technical debt in relation to the DoD?

A weak or ignored DoD leads to technical debt because shortcuts slip into production undetected. A strict DoD helps prevent debt by enforcing code review, testing, and documentation for every change.

How does the DoD differ from a Definition of Ready?

The Definition of Ready lists conditions a backlog item must meet before entering a sprint (e.g., user story written, dependencies identified). The Definition of Done lists conditions an item must meet to exit the sprint as potentially shippable.

Who owns the DoD?

The Scrum Team owns the DoD collectively, but the Scrum Master facilitates updates and the Product Owner confirms that it aligns with market and compliance needs.

How often should we review the DoD?

Inspect the DoD in every Sprint Retrospective. Update it when new risks appear or tooling makes a quality gate cheaper.

What tools help enforce the DoD?

Continuous-integration pipelines (GitHub Actions, GitLab CI), code-review checklists, static-analysis tools (SonarQube), and automated deployment gates all enforce specific DoD steps.