What Is Definition of Done in Scrum? A Complete Guide with Examples

what is definition of done in scrum is a key topic in modern project management and teamwork. Two developers mark the same story “done.” One means “code committed.” The other means “code committed, reviewed, tested, documented, and deployed to staging.” The sprint closes, the increment goes to the Sprint Review, and the team discovers half the “finished” work is not actually usable — the Product Owner refuses to release it, and the definition of “done” turns out to have meant different things to every person in the room.

That single failure — an unshared, unwritten, or unenforced Definition of Done — quietly undermines Scrum teams more than any other practice. This guide explains what the Definition of Done is in Scrum, why the Scrum Guide treats it as a commitment, how it differs from acceptance criteria and the Definition of Ready, and how to write one that your team will actually enforce.

Quick Answer: What Is the Definition of Done in Scrum?

The Definition of Done in Scrum is “a formal description of the state of the Increment when it meets the quality measures required for the product.” It is the commitment of the Increment artifact in the Scrum Guide: a shared checklist that every Product Backlog item must pass before the team considers it done. When an item meets the Definition of Done, an Increment is born; if it does not, the work cannot be released or presented at the Sprint Review and goes back to the Product Backlog.

The nuance: the DoD is not a wish list. It is the minimum quality bar the team can consistently meet — and, like the team itself, it is expected to evolve upward over time.

What Is the Definition of Done, Exactly?

The official definition comes from the 2020 Scrum Guide, which lists three artifacts — the Product Backlog, the Sprint Backlog, and the Increment — and each artifact carries a commitment. The Increment’s commitment is the Definition of Done:

> “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”

Two consequences follow from that definition. First, “done” stops being a personal judgment. It becomes a written, inspectable checklist that the whole team shares. Second, it is a *quality* bar, not a scope list — it answers “is this work actually finished to the level we promised?” rather than “did we type all the tasks?”

The Scrum Guide is explicit about the mechanics:

• The moment a Product Backlog item meets the Definition of Done, an Increment is born.
• If a Product Backlog item does not meet the DoD, it cannot be released or even presented at the Sprint Review. It returns to the Product Backlog for future consideration.
• The Developers are required to conform to the Definition of Done, and instilling quality by adhering to it is one of their explicit accountabilities.

That is why the DoD is not a nice-to-have. In Scrum, “done” is a defined term with a defined test.

Why Does the Definition of Done Matter?

The DoD exists for one reason: transparency. The Scrum Guide builds the whole framework on three pillars — transparency, inspection, and adaptation — and the DoD is the transparency mechanism for completed work.

Without a DoD, three problems appear immediately:

1. Every person has a private definition of done. A developer’s done is “code pushed,” a tester’s is “tests green,” a Product Owner’s is “releasable.” The team talks past itself and discovers the mismatch at the Sprint Review, when it is expensive.
2. Quality is invisible and unenforceable. When “done” is unspoken, a team under pressure quietly drops tests, documentation, or reviews to look faster — and the quality debt is discovered months later.
3. Forecasting breaks. Velocity, burndowns, and release forecasts all count “done” work. If done is ambiguous, every number built on it is fiction.

With a DoD, the Sprint Review becomes a real inspection (“does this increment meet our agreed bar?”), the Sprint Retrospective has a concrete element to inspect (“how did we do against our DoD this sprint?”), and planning conversations become honest (“that story is not done — it did not pass code review, so it does not count toward our velocity”).

Definition of Done vs Acceptance Criteria: What Is the Difference?

This is the most common source of confusion, and the difference matters:

Acceptance criteria describe what a feature must *do*. The DoD describes the standard every feature must *meet to count as done*. Both can include “tests pass” — but an item-level criterion might say “the payment flow passes 3 checkout scenarios,” while the DoD says “all committed code is covered by passing automated tests before it leaves the team.”

A useful way to see it: acceptance criteria define the feature’s contract with the user; the DoD defines the team’s contract with itself and the organization.

Definition of Done vs Definition of Ready: What Is the Difference?

The Definition of Ready (DoR) is a related but different checklist: it describes what must be true *before* a Product Backlog item is brought into a sprint, while the DoD describes what must be true *after* the work is finished.

The DoR is not part of the Scrum Guide’s official artifact commitments — it is a widely used practice that teams adopt to make Sprint Planning smoother. If an item is not “ready,” the team wastes sprint time discovering what it is supposed to build. If an item is not “done,” the team claims value it never actually created. Both checklists matter; they guard opposite ends of the same workflow.

What Are Good Examples of a Definition of Done?

A DoD is a checklist, and good ones are short enough to remember and specific enough to verify. Here are realistic examples by team type:

The exact items depend on your domain and your organization’s standards. The Scrum Guide’s requirement is structural, not prescriptive: if your organization has standards, your DoD must meet them as a minimum; if it does not, your team must create one appropriate for your product.

How Do You Create Your Team’s Definition of Done?

Creating a DoD is a team exercise — the Developers who do the work must own it, or they will not honor it. The process:

Step 1: Audit what “done” currently means

Gather the team and ask, item by item: “what do we currently consider done?” List every informal practice — a developer mentally checks tests, a tester checks the ticket’s status. Write them all down, including the disagreements. The disagreements are the point of this step.

Step 2: Draft the checklist from the audit

Turn the list into a verifiable checklist. Every item must be observable: “code reviewed” is better than “good quality”; “automated tests pass in CI” is better than “tested”. Keep it to the essential quality bar — usually 5 to 10 items. A 20-item DoD is a document nobody reads.

Step 3: Check the floor

If the organization has published standards (coding standards, security policies, legal review requirements), incorporate them as mandatory items. Organization-level DoD outranks team-level wishes in Scrum: “If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum.”

Step 4: Agree and write it down

The whole team reviews, argues, and agrees on the final checklist. Post it where the team works — a board, a channel, a wiki — because a DoD nobody can see is a DoD nobody follows. For multi-team products, the teams must mutually define and comply with the same DoD.

Step 5: Enforce it in the Sprint Review and Retrospective

At the Sprint Review, check presented items against the DoD: anything failing goes back to the Product Backlog, no exceptions. In the Retrospective, inspect the DoD itself: is it being met? Is it too easy (so the team is coasting) or too strict (so nothing ever ships)? Adjust deliberately, as a team.

Step 6: Evolve it on purpose

The DoD should tighten over time. A team new to automated testing might start with “manual test passes” and add “automated regression suite” once the infrastructure exists. Wikipedia’s description of the practice puts it plainly: as the team improves, the DoD should evolve to align with what is needed for work to be released.

Real Scenarios: Definition of Done in Practice

Scenario 1: The 30% phantom increment

A seven-person software team has no written DoD. In the Sprint Review, the Product Owner asks for a demo of the “finished” reporting feature. Three stories in the Sprint Backlog are marked done, but two of them have no automated tests, one was never deployed to the staging environment, and the reporting feature only works with mocked data. The demo fails in front of stakeholders. The team calculates the true releasable value of the sprint: roughly 70% of the committed points actually met a reasonable quality bar. The cost of the missing DoD was a failed review, stakeholder distrust, and a sprint whose real output was a third smaller than planned.

Scenario 2: The DoD that caught a quality cliff

A content team adopts a simple DoD: draft → edited by a second person → brand/voice check → sources/licensing verified → scheduled. For two sprints the checklist feels bureaucratic, then it pays off: a writer tries to mark an article done without a voice check. The checklist stops it. Three months later, the team estimates the checklist has prevented at least 6 articles from shipping with off-brand language or unlicensed images — issues that would have surfaced publicly and cost far more than the five-minute check. The DoD turned “done” from a guess into a gate.

Scenario 3: The team that set its bar too high

An ambitious engineering team writes a 15-item DoD including full end-to-end coverage, security penetration checks on every story, and release-grade documentation. Two sprints in, nothing meets the DoD, velocity collapses to near zero, and the Sprint Review has nothing to show. The DoD was a wish list, not a quality bar. In the Retrospective the team trims it to the achievable minimum — code reviewed, automated tests for the change pass, staging deployment, no open criticals — and commits to tightening it one item per quarter as their tooling improves. The lesson: the DoD is “how close the team can reasonably get with its existing capabilities,” not the abstract ideal.

Scenario 4: Multi-team alignment on one product

Three Scrum teams work on one product. Team A’s DoD includes “deployed to production,” Team B’s stops at “deployed to staging,” and Team C has no deployment item at all. The release train keeps stalling because teams disagree on when work is truly done. The organization steps in: a single product-level DoD is defined (code reviewed, tests pass in CI, staging verified, production release approved), applied as the floor for all three teams, and each team may add stricter items above it. Releases start landing predictably because “done” finally means the same thing across teams.

Common Mistakes When Creating or Using a Definition of Done

• Not having one at all. The single most common failure. “Everyone knows what done means” is never true.
• Confusing DoD with acceptance criteria. Item-specific criteria are necessary, but they do not replace the team-level quality bar.
• Making it a wish list. A 20-item DoD that nothing ever meets destroys credibility. Start with the achievable minimum and tighten deliberately.
• Letting one person decide. If the Product Owner (or a manager) writes the DoD alone, the team will not honor it. The Developers must own it.
• Keeping it invisible. A DoD in a shared drive nobody opens is a DoD nobody uses. Post it where the team works.
• Not enforcing it. If a story fails the DoD but still gets counted as done, the checklist becomes decoration within two sprints.
• Never evolving it. A DoD that does not tighten as the team improves lets quality rot silently.
• Counting DoD-failing work in velocity and forecasts. Every metric built on “done” inherits the DoD’s integrity — or lack of it.
• Ignoring organization standards. If your org has standards and your team’s DoD is weaker, you are not doing Scrum as defined.

Know This Before You Choose

Before you write your team’s Definition of Done (or choose the tool that carries it), answer these questions:

• What does “done” mean for each role on this team today — and where do those answers disagree?
• What is the minimum quality bar the team can honestly meet every sprint, not the ideal it hopes to reach?
• Which items are verifiable (code reviewed, tests pass, scheduled) rather than vague (good quality, no bugs)?
• Are there organization standards the DoD must satisfy as a floor?
• If multiple teams share the product, is the DoD mutually defined and identical across teams?
• Who will enforce it at the Sprint Review — and what happens when an item fails it?
• How will the team see it daily — posted on a board, a wiki page, inside the tool?
• How often will the team review and tighten it in the Retrospective?

Which Tools Help You Manage a Definition of Done?

A few real options, each with honest trade-offs:

• Jira (Atlassian) — store the DoD in a Confluence page linked to the project, or use a “Definition of Done” checkbox custom field on issue screens. Pros: keeps the checklist in the same place as the work; reportable. Cons: enforcement is manual — the checkbox can be ticked by anyone. Best for software teams already on Jira/Confluence.
• Confluence — a shared, team-editable page for the DoD. Pros: versioned, easy to review and update, links to Jira. Cons: it is documentation, not enforcement; the checklist must still be applied at review time. Best for documentation-heavy teams.
• Asana / ClickUp — use checklist sub-tasks or custom fields as a per-item DoD gate. Pros: the checklist travels with each task, so it is hard to skip. Cons: team-level DoD is not a built-in concept; you maintain it as a template. Best for non-software and hybrid teams.
• GitHub Projects / GitLab — enforce DoD-style gates with issue templates, required reviews, and CI checks. Pros: part of the pipeline; automated checks are hard to bypass. Cons: requires engineering setup; less accessible to non-technical team members. Best for developer-led teams.
• Spreadsheets / docs — a simple checklist stored anywhere shared. Pros: free, universal. Cons: invisible and unenforced; dies without a ritual. Best for tiny teams as a starting point.

The trade-off pattern repeats everywhere: a tool can store the DoD and even remind the team, but only the team’s discipline — a real review, a real gate — enforces it. No tool fixes a DoD nobody uses.

When a Tool Makes the Definition of Done Real

If you have watched a DoD die inside a document nobody opens, a tool that embeds quality checks into the work itself is worth looking at. This is one of those decisions where your project management platform either carries the checklist into the workflow or leaves it as a separate document to ignore. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. In Doitify, tasks carry checklists and quality control (QC), so the team’s definition of done can live on every task as a checklist that must be satisfied before work is closed — while owners, due dates, and progress stay visible across boards, sprints, and work reports. That turns “done” from a word into a checkable state inside the workflow itself. If your team’s reviews keep tripping over work that was “done” but never checked, that built-in QC is the use case it was designed for; if your current checklist works, keep it.

Conclusion

The Definition of Done is the small agreement that keeps Scrum honest: a written, shared checklist that defines when an Increment is actually finished. It creates transparency where private definitions of “done” would otherwise hide quality debt; it gives the Sprint Review a real gate and the Retrospective a real subject to inspect; and it makes velocity, burndowns, and forecasts trustworthy by ensuring they only count genuinely complete work. Write it as a team, start with the achievable minimum, post it where everyone can see it, enforce it at every review, and tighten it as you improve. Do that, and “done” will finally mean the same thing to everyone in the room.