Definition of Done

Definition: The Definition of Done (DoD) is a shared checklist that work must pass before anyone calls it finished. It turns "I think it's done" into a yes-or-no gate every team member reads the same way, so nothing half-finished slips into a release.

A good Definition of Done is the difference between "the developer says it works" and "it is tested, reviewed, documented, and ready for users." It removes the gray zone where one person's "done" is another person's "still needs work."

You already run a version of this in your head. Before you send an invoice, you check the amount, the client name, and the due date. The DoD just writes that mental checklist down so the whole team runs the same one, every time.

TL;DR: A Definition of Done is the shared checklist every Agile or Scrum item must clear before it counts as finished, code reviewed, tested, documented, deployed. One DoD applies to every Sprint item; per-item rules live in acceptance criteria. Run yours as a visible Board gate, one of 150,000+ apps built with Taskade Genesis. Build a checklist board with AI →

What Is the Definition of Done in Agile?

The Definition of Done is a single, team-wide checklist of conditions that any work item must satisfy to be considered complete. It applies to every item in the Sprint Backlog, not one story. When a task meets every line on the list, it is done. When it misses even one, it is not.

The DoD lives with the team, not with a single manager. The whole team agrees on it, so "done" means the same thing whether the developer, the tester, or the product owner is the one saying it.

Why the Definition of Done Matters

A clear Definition of Done prevents the most expensive Agile failure: work that looks finished but breaks later. Without a shared standard, items pile up in a "done" column that still need testing, review, or deployment. The DoD makes quality visible up front so problems surface during the Sprint, not after release.

It also protects velocity. When the team counts only truly-finished work, velocity reflects real output, not optimistic guesses. That makes release planning honest and estimation more reliable over time.

The Done Gate at a Glance

Every work item runs the same gauntlet. It passes from one check to the next, and any failure sends it back to in-progress. Only an item that clears all checks reaches the Done column.

What Belongs in a Definition of Done

A strong Definition of Done covers the full lifecycle of a work item, from code to customer. The exact lines vary by team, but the categories below show up on almost every healthy DoD. Keep each line testable: a reviewer should be able to answer yes or no without debate.

How to Create a Definition of Done

Build the Definition of Done as a team, in one short working session, then refine it as you learn. The goal is a list short enough that everyone remembers it and strict enough that "done" actually means done. Follow these steps:

• Gather input from the whole team. Include development, testing, product, and any compliance voices so the DoD covers every angle of the work, not just the coding side.

• Set clear quality standards. Name what "good" means: performance targets, security requirements, accessibility, and design-spec adherence. Vague standards produce vague results.

• Be specific and realistic. Write lines a reviewer can check with a yes or no. Set the bar high enough to protect quality but reachable inside one Sprint cycle.

• Add compliance and regulatory requirements. If your work must meet a standard or regulation, put that line in the DoD so it never gets skipped under deadline pressure.

• Review and revise regularly. Revisit the DoD in Sprint Retrospectives. As the team and product mature, raise the bar and retire lines that no longer add value.

Definition of Done Checklist Template (Copy and Edit)

A Definition of Done checklist template is a short list of yes-or-no lines a team copies, trims to its own work, and pins where everyone sees it. The 2020 Scrum Guide calls the Definition of Done "a formal description of the state of the Increment when it meets the quality measures required for the product" and says an Increment is born the moment an item meets it. Use this as a starting point:

Five to ten lines is enough. Delete any line the team never fails, and add a line the first time a defect slips through. A non-software team can use the same shape: "draft reviewed," "figures checked," "approved by the client," "published."

Two rules from the Scrum Guide keep it honest. If an item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review, and it returns to the Product Backlog. And if an organization already has a standard, the team must follow at least that.

Definition of Done in 2026: Where AI Agents Fit

An AI agent can check the boring lines of a DoD so people spend review time on judgment. The team still owns the definition and the final yes.

• Pre-review pass: an agent reads the card and the linked notes and lists which checklist lines have evidence and which do not.
• Docs and release notes: an agent drafts the summary from the completed items for a person to edit.
• Retrospective input: an agent reads the past sprint's cards and flags the DoD lines that were missed most often, so the team decides whether to change the line.

An agent works only from what it can read, so evidence on the card (links, names, dates) is what makes the check useful. In Taskade, the checklist lives in a project, a custom agent can read it as knowledge, and an automation can notify the reviewer when the last box is ticked.

Definition of Done vs Acceptance Criteria

The Definition of Done and acceptance criteria are both completion gates, but they work at different scopes. The DoD is one universal checklist for every item in the Sprint. Acceptance criteria are specific, written per-item conditions tied to a single user story. An item must satisfy both: the shared DoD and its own acceptance criteria.

What a Done Gate Looks Like on a Board

The clearest place to enforce a Definition of Done is a Kanban board with a column the item cannot enter until every check passes. The DoD lives as a checklist on each card. The board makes the gate visible to the whole team at a glance.

┌─────────────┬─────────────┬─────────────────────┬───────────┐
│   TO DO     │ IN PROGRESS │   DONE GATE ▸ check │   DONE    │
├─────────────┼─────────────┼─────────────────────┼───────────┤
│ Login form  │ Export CSV  │ Payment flow        │ User auth │
│ Reset email │             │  ☑ code merged      │ Dashboard │
│ Audit log   │             │  ☑ peer reviewed    │           │
│             │             │  ☑ tests pass       │           │
│             │             │  ☐ docs updated  ◀  │           │
│             │             │  ☐ deployed to stg  │           │
└─────────────┴─────────────┴─────────────────────┴───────────┘
   Card stays in the gate until every box is ticked, then moves to Done.

Related Terms and Concepts

• Agile Methodology: Framework for iterative, incremental project management.
• Scrum: A method that sets project success criteria per Sprint.
• Sprint: A short, consistent cycle for completing designated work.
• Sprint Backlog: The set of items the team commits to in a Sprint.
• Product Backlog: Ranked list of project tasks and requirements.
• User Stories: Plain-language descriptions of a feature from the user's view.
• Velocity: How much done work a team completes per Sprint.

Frequently Asked Questions About the Definition of Done

What is a Definition of Done checklist?

A Definition of Done checklist is the written list of conditions every item must meet before the team calls it finished, such as merged, reviewed, tested, documented, and verified. Each line is a yes-or-no test, so two people always reach the same answer.

Is there a Definition of Done template I can copy?

Yes. Start with the template above: code, review, tests, docs, and release lines. Trim it to what your team actually fails, keep it to five to ten lines, and revisit it in each retrospective.

What are Definition of Done examples for non-software teams?

A content team can use "draft reviewed, facts checked, approved, published." A design team can use "handoff file complete, accessibility checked, stakeholder signed off." The idea is the same: a shared, testable bar.

How does the Definition of Done differ from acceptance criteria?

The Definition of Done applies to every item in the Sprint and ensures each one meets the team's shared standard of finished. Acceptance criteria are specific conditions for one user story that the product owner defines. An item must pass both before it ships.

Can the Definition of Done change over time?

Yes. The Definition of Done should evolve as the team learns and the product matures. Review it during Sprint Retrospectives, raise the bar when quality habits stick, and retire lines that no longer add value. A DoD that never changes usually means no one is reading it.

Is the Definition of Done the same for every team?

No. The Definition of Done reflects each team's context, the product's complexity, stakeholder needs, and the team's way of working. A medical-software team carries compliance lines a marketing-site team does not. Each team writes a DoD that fits its own quality standards.

Who is responsible for the Definition of Done?

The whole team owns the Definition of Done, not a single manager. Developers, testers, and the Scrum Master all shape it and all enforce it. Shared ownership is what makes "done" mean the same thing no matter who says it.

What happens when an item does not meet the Definition of Done?

The item is not done. It stays in progress and returns to the team to finish the missing checks. Counting unfinished work as done inflates velocity and hides risk, which is exactly what the DoD exists to prevent.

How long should a Definition of Done be?

Short enough that the team remembers every line, usually five to ten checks. A DoD nobody can recall is a DoD nobody follows. Keep each line testable with a clear yes or no, and cut anything that does not change whether work is truly finished.

Build Your Definition of Done as a Living Board

A Definition of Done is only as strong as how visibly you enforce it. In Taskade Genesis, you can turn that checklist into a working pipeline from one plain-English prompt. Describe your delivery process and you get a Board where every work item moves through a Done Gate column, with the DoD as a checklist on each card that has to be fully ticked before the item reaches Done.

Your team sees the same gate in real time. The card cannot reach Done with an open box, a reliable automation workflow pings the reviewer the moment all checks pass, and your velocity finally counts only truly-finished work. No spreadsheet to babysit, no "is this actually done?" thread in chat.

You already keep this checklist in your head. Put it on a board the whole team reads the same way. Start with a Definition of Done board in Taskade Genesis →