What is a Definition of Done?
Definition of Done
A Definition of Done is the checklist a team agrees on in advance that decides whether a piece of work is finished, not started or mostly complete.
A Definition of Done (DoD) is a checklist a team agrees on before work starts, listing everything that has to be true for a task, deliverable, or sprint to count as finished. It exists because "done" is a word people define differently by default: done to a designer might mean the file is exported, while done to the client means it's been reviewed and approved.
Without a written DoD, that gap surfaces at the worst possible moment, during a sprint review or a client handoff, when something presented as complete turns out to need another round of work. A DoD closes that gap before it opens, by making the finish line explicit and identical for everyone touching the work.
The DoD is a Scrum artifact by origin, tied to the Increment at the end of a sprint. But the underlying idea, agree on completion criteria before you start, applies to any team producing deliverables, Scrum or not.
Definition of Done vs Acceptance Criteria
These two get confused constantly because both describe when something is finished. The difference is scope: the DoD applies to every piece of work the team produces, while acceptance criteria are written for one specific item and describe what "correct" looks like just for that item.
| Definition of Done | Acceptance Criteria | |
|---|---|---|
| Applies to | Every task or deliverable, universally | One specific item |
| Who writes it | The whole team, once, revisited periodically | Whoever requests that specific item |
| Answers | Did we follow our process? | Did we build the right thing? |
| Example | Reviewed by a second team member before marking done | The signup form rejects emails without an @ symbol |
Definition of Done Has Levels
Most teams write one DoD and apply it everywhere, which works until a five-minute fix and a three-week feature get held to the same seven-step checklist. A better structure has done criteria at more than one level, each one building on the last.
- Task-level: the smallest unit is complete, code committed, copy written, asset exported
- Deliverable-level: the task-level items plus review and approval, a design reviewed by a second designer, copy checked against brand voice
- Sprint-level: every deliverable in the sprint meets its own DoD, and the increment as a whole is demoable
- Release-level: sprint-level criteria plus anything only relevant at launch, QA across browsers, client sign-off, documentation handed over
Writing a Definition of Done by Work Type
A DoD works best written per type of deliverable, not as one generic list for the whole team. A development task, a design file, and a piece of copy each finish under different conditions.
| Work type | Typical Definition of Done |
|---|---|
| Development task | Code reviewed, tested, merged, no known bugs, deployed to staging |
| Design asset | Reviewed by a second designer, matches brand guidelines, exported in required formats |
| Copy or content | Proofread, checked against brand voice, approved by the account lead |
| Client deliverable | Internal review complete, client has approved in writing, final files delivered |
A Worked Example: DoD for a Client Landing Page
A 7-person agency team writes this Definition of Done for landing pages before starting a retainer client's campaign work, so every page ships to the same standard regardless of which designer or developer built it.
- Copy proofread and approved by the account lead
- Design reviewed by a second designer against the brand guidelines
- Page built and responsive across desktop, tablet, and mobile breakpoints
- All links tested, including form submissions
- Page loads in under 3 seconds on a standard connection
- Analytics tracking installed and verified
- Client has reviewed a staging link and approved in writing
How the DoD Gets Enforced Day to Day
The DoD only works if moving a card to "Done" actually requires meeting it, not just feeling finished. The person closing a task should check it against the list before moving it, and anyone else on the team should be able to reopen a task that skipped a step without it being treated as a conflict.
For sprint-based teams, the sprint review is the checkpoint that catches DoD gaps at scale. Work presented as complete that doesn't meet the agreed criteria goes back to the backlog, not into the next sprint's carryover pile disguised as done.
Updating the DoD Over Time
A Definition of Done written once at project kickoff and never revisited tends to fall behind reality. When a defect slips through to a client because a step was missing, that's the signal to add it, not to rely on everyone remembering next time.
The retrospective is the natural place to update it: when a team identifies that something reached a client incomplete, the fix is usually one new line in the DoD, not a longer lecture about being careful. Review the list every quarter or after any incident where finished work turned out not to be.
In Melororium
Set completion checklists on tasks in Melororium
Common mistakes with definition of done
What teams get wrong most often, and what to do instead.
- 1
One-size-fits-all Done
Using an identical checklist for a five-minute fix and a three-week feature. Trivial tasks drag through steps that don't apply, and complex ones quietly skip steps that do.
- 2
A DoD nobody reads after kickoff
Writing the list once, pinning it in a document, and enforcing it from memory. What the team actually checks drifts from what's written within a month.
- 3
Confusing Definition of Done with Definition of Ready
The DoD governs when work finishes; a Definition of Ready governs when work is allowed to start. Mixing the two up means half-specified work enters a sprint, and finished work gets rejected for the wrong reason.
- 4
Bending the checklist under deadline pressure
Skipping the review step to hit a launch date, with a plan to "catch it after." Unreviewed work reaching a client is exactly what the checklist existed to prevent.
Frequently asked questions
What's the difference between Definition of Done and acceptance criteria?
Definition of Done applies to every piece of work the team produces, written once and reused. Acceptance criteria are written for one specific item and describe what correct looks like just for that item. A task needs to satisfy both.
Does every task need to meet the full Definition of Done?
Yes, at whatever level applies to it. A quick internal fix might only need the task-level DoD, while a client deliverable needs the full deliverable-level checklist including review and approval.
Who writes the Definition of Done?
The whole team that does the work, not just a manager or Scrum Master. A checklist imposed from outside gets followed loosely; one the team wrote themselves gets enforced by the team itself.
Can the Definition of Done change mid-project?
Yes. It should evolve when a gap surfaces, most often at a retrospective after something incomplete reached a client. Update it, tell the team, and apply the new version going forward.
How does Melororium help enforce a Definition of Done?
Tasks in Melororium carry subtasks and a review step before a card can move to Done, so the checklist lives on the task itself instead of in a separate document nobody opens.
