definition of done

A short checklist the team applies to every piece of work before calling it finished, such as reviewed, tested and documented. Acceptance criteria are specific to one deliverable; the definition of done is the same for all of them.

A definition of done is a short checklist the team applies to every piece of work before calling it finished. For software it might be "reviewed by a second developer, tested, released"; for content, "a second person has checked a sample, formatted to the style sheet, works on a phone, signed off". It answers the question "done according to whom?" once for the whole team, so "done" stops meaning "done by me, waiting for someone else".

It differs from acceptance criteria in scope. Acceptance criteria belong to one deliverable: what this landing page must do for families. The definition of done is the same for all of them. A piece of work needs both: it meets the deliverable's own criteria and the team's common checklist.

Good lines are checkable by someone other than the author (yes or no, not "good quality"), and the list stays short enough to apply every time, usually four to six lines. It covers both content (correctness checks) and usability (it opens, it reads, it is tagged), plus a sign-off where one is needed.

The definition of done is how quality gets built into the work instead of inspected at the end: each piece is checked as it lands, not in one big review the week before launch. In short iterations, only pieces that meet it are shown as finished at the weekly demo. Agree it before the work starts, and change it in a retrospective rather than quietly under deadline pressure.

Example

Klasna's physics team writes a definition of done for every practice set topic (December 2026):

Every task has a worked answer, and a second tutor has solved the first ten without errors.
Units and notation follow the curriculum's style sheet.
Every diagram is present and readable.
Tasks are tagged by exam topic and difficulty.
The set opens and reads correctly on a phone.
Vira has signed off the topic in the shared tracker.

It sits next to the acceptance criteria of one deliverable, the practice sets for units 1–3 (likely 12 person-days, 72,000 UAH of the budget):

	Definition of done	Acceptance criteria
Applies to	Every topic of every set	This deliverable only
When it's checked	As each topic lands	When the whole deliverable is handed over
Example check	A second tutor solves the first 10 tasks of the topic	Vira solves a random sample of 20 tasks from the whole set

In January, when the work runs in one-week iterations, the Friday demo shows only the topics that meet all six lines; a topic "almost done" stays in progress.

Common mistakes

Mixing it up with acceptance criteria. One checklist for all work, versus conditions for one deliverable; a piece needs both.
Lines nobody can check. "High quality" or "no mistakes" without a check is a wish.
A list too long to use. Twelve lines get skipped under pressure; keep four to six.
One big inspection at the end. Check each piece as it lands, not everything the week before launch.
Bending it under deadline pressure. Change the definition openly in a retrospective, not by quietly skipping a line.

Learn it in the course

Risk responses, the pre-mortem and built-in quality · Choose a response for each risk (avoid, transfer, reduce, accept or escalate), use opportunities, find hidden risks with a pre-mortem, and check quality while the work is done, not at the end.
Acceptance criteria: what "done" means · "Good lessons" is a wish nobody can accept. Write checks a named person can run, agree them before the work starts, and say what happens when one fails.