# Definition of done vs acceptance criteria

> A definition of done is a team-wide checklist every task must meet. Learn how it differs from acceptance criteria, with an example list to adapt.

The definition of done is the checklist every piece of work must pass, for the whole team. Acceptance criteria say what one task must do. You need both.

Web page: https://kansohq.app/guides/definition-of-done

Updated: 5 October 2026

## What a definition of done is

A definition of done, often shortened to DoD, is a short list of things that must be true of any piece of work before the team calls it finished. It is agreed once, applies to every task and is the same for everyone. It exists to end the argument about whether something is “really done”.

## How it differs from acceptance criteria

|  | Acceptance criteria | Definition of done |
| --- | --- | --- |
| Belongs to | One task | The whole team |
| Says | What this task must do | What every task must go through |
| Written by | The person who asked for the work, with the builder | The team, together |
| Example | “The banner names both versions of a conflict” | “Reviewed, tested and documented” |

A task is finished when its own [acceptance criteria](https://kansohq.app/guides/how-to-write-acceptance-criteria.md) are met and the definition of done is satisfied. The first says the right thing was built; the second says it was built well.

## An example to adapt

**A definition of done for a software team**

> The code is reviewed by one other person.
> Automated tests pass, and new behavior has tests.
> The acceptance criteria on the task are all met.
> The change works on the staging environment.
> Documentation and release notes are updated where needed.
> The task is moved to Done, and anything left over is a new task.

## How to build one

1. Ask the team what has gone wrong after a task was called done: a missing test, no documentation, a bug found in staging.
2. Turn each answer into a line that is either true or false.
3. Keep it to five to eight lines. A long list will be ignored.
4. Put it where the team will see it every day, beside the board.
5. Review it in each retrospective and change a line when the team learns something.

## Mistakes to avoid

- A definition of done that only one person wrote.
- Lines that cannot be checked, such as “high quality”.
- Letting it quietly lapse when a deadline is close. That is when it matters most.

## Definition of ready, the other end

The definition of done says when work is finished. A **definition of ready** says when work is ready to start: the task is small enough, it has acceptance criteria, its dependencies are known and someone has agreed to own it. It stops half-understood work from entering the board. Keep it just as short, and use it as a conversation, not a gate that blocks urgent work.

## How it grows with the team

| Team | A reasonable definition of done |
| --- | --- |
| A new team of two or three | Works, reviewed by another person, merged |
| A team with testers and releases | Reviewed, tested, acceptance criteria met, release notes updated |
| A mature team with many users | The above, plus monitored in production, documented and checked against its success measure |

## When it collides with a deadline

A definition of done is tested by a deadline. When time is short, resist the urge to quietly skip a line. Cut scope instead, so that what ships is still done. If a line really must be skipped, say so out loud, record the debt as a task with an owner and a date and keep the promise to pay it back.

## Doing it in Kanso

Put the team’s definition of done at the top of each [board](https://kansohq.app/product/boards.md) in a short note, and use each card’s acceptance criteria for what is specific to that task. For launches, the [launch checklist template](https://kansohq.app/templates/launch-checklist.md) is a definition of done for the release as a whole.

## Questions

### What is a definition of done?

A definition of done is a short, team-wide checklist that every piece of work must meet before it counts as finished, for example reviewed, tested and documented.

### What is the difference between acceptance criteria and a definition of done?

Acceptance criteria belong to one task and say what it must do. The definition of done belongs to the whole team and applies to every task.

### How long should a definition of done be?

Five to eight lines. A longer list is skimmed and then ignored.

### Who owns the definition of done?

The whole team agrees it, and reviews it regularly, for example in the retrospective.

## Keep reading

- [How to write acceptance criteria, with examples](https://kansohq.app/guides/how-to-write-acceptance-criteria.md): Acceptance criteria say when a task is done. Learn how to write them as clear true-or-false lines, with examples and a checklist for software teams.
- [How to run a retrospective that changes something](https://kansohq.app/guides/how-to-run-a-retrospective.md): A retrospective is only worth it if something changes afterwards. Learn a simple format, how to run it in an hour and how to follow through.
- [How to plan a software release, step by step](https://kansohq.app/guides/how-to-plan-a-software-release.md): Plan a software release in seven steps: fix the date, freeze the scope, split the work by team, track blockers and decide go or no-go. With a checklist.
- [Feature spec template with acceptance criteria | Kanso](https://kansohq.app/templates/feature-spec.md): A feature spec template with how it behaves, acceptance criteria, edge cases and what you are not doing. Copy it, or start it as a page in Kanso.
- [Software launch checklist template to copy | Kanso](https://kansohq.app/templates/launch-checklist.md): A software launch checklist template covering product, quality and go-to-market, launch day and after launch. Copy it, or start it in Kanso.

## Parts of Kanso used

- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.
- [Kanso Docs](https://kansohq.app/product/docs.md): Pages with headings, to-dos, tables and code, kept inside the project they describe, next to its board and its release.

[Kanso home, with plans and prices](https://kansohq.app/index.md)