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.
| Category | What the checklist line looks like | Why it belongs |
|---|---|---|
| Code | Code complete and merged to the main branch | No orphaned branches counted as done |
| Review | Peer reviewed and approved by a second person | Catches defects before they ship |
| Testing | Unit and integration tests written and passing | Proves the work behaves as intended |
| Documentation | User-facing and internal docs updated | The next person can use and maintain it |
| Quality standards | Meets performance, security, and accessibility bars | "Works" is not the same as "works well" |
| Deployment | Deployed to staging and verified | Done means runnable, not just written |
| Compliance | Regulatory and design-spec requirements met | Keeps the team out of legal and brand risk |
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 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.
| Definition of Done | Acceptance Criteria | |
|---|---|---|
| Scope | All items, team-wide | One specific story |
| Who owns it | The whole team | The product owner |
| How often it changes | Stable, revised occasionally | New for each story |
| Question it answers | "Is this up to our standard?" | "Does this do what was asked?" |
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
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 →