Skip to content

Definition of Done

At a glance

  • Purpose: Agree what "finished" means, so completed work is genuinely releasable rather than merely written.
  • Use it when: Before the first iteration, and revisited whenever quality problems recur. It applies to every item, without exception.
  • Owner: The team owns it; the product owner and quality role agree it is meaningful to the customer.
  • Related: Module 09 · Lab 20

How to use this template

  1. Write what is observably true of finished work. Every line should be verifiable at the review.
  2. Include the expensive-to-add-later items — testing, review, documentation, deployment readiness — or they will be deferred to the end, which is where they cause overruns.
  3. Keep "done" distinct from "released". A definition of done is an engineering standard; a release decision is a business one, possibly with staged rollout.
  4. Agree explicitly whether unfinished work is returned to the backlog or carried. Carrying part-done work is the most reliable way to hide slippage.
  5. Tighten it deliberately as the project matures, and record what changed — a rising standard is healthy, an unexplained one looks like moving goalposts.

Field descriptions

Field What goes in it Watch out for
Criterion An observable property of finished work Aspirations rather than standards
Evidence Where the proof lives (pipeline, review, test run) "Tested by the developer"
Applies to Every item, or a named category Quiet exemptions for small items
Exclusions What is deliberately outside the standard Exclusions that hollow it out
Tightening plan What will be added at which point Standards raised without capacity to meet them

Blank template

# Definition of Done — [Team or project]

| | |
| --- | --- |
| **Version** | [1.0] |
| **Agreed by** | [Team, product owner] |
| **Applies to** | [All backlog items / increments] |

| # | Criterion | Evidence |
| --- | --- | --- |
| 1 | Code is reviewed by someone other than its author and the review is closed | Review record |
| 2 | Unit and integration tests are written and pass in the pipeline | Build result |
| 3 | Acceptance criteria are demonstrated against real or realistic data | Demonstration at review |
| 4 | No known defect of severity P1 or P2 is open against the item | Defect log |
| 5 | Documentation the user or operator needs is updated | Documentation link |
| 6 | The change can be deployed by the standard process, and deployment is verified | Deployment log |
| 7 | Non-functional criteria for the item (performance, accessibility, security checks) are met | Test or review evidence |

## Not included in this definition

- [e.g. Release to production — a separate business decision made per release]
- [e.g. Training material for a feature with no user-visible change]

## Exceptions

| Date | Item | Criterion | Reason | Approved by | Follow-up |
| --- | --- | --- | --- | --- | --- |

## Change history

| Date | Change | Reason |
| --- | --- | --- |

Worked example

From Lab 20, invented for teaching. The team adopts the seven criteria above, and the sprint review produces:

Item Claimed status Verified status Why
Upload a supporting document Done Done All seven criteria evidenced, including a 5 MB upload test
Eligibility rules engine Done Not done Criterion 3 fails: demonstrated against 12 hand-built cases only, with no negative cases
Admin console list view Done Not done Criterion 7: the list page has no pagination and times out above 500 records

Both "not done" items were genuinely built — the failure is that finished work was declared finished without the standard being applied. The consequence is what matters pedagogically: the eligibility engine's missing negative cases reappear as a defect cluster after release, and the pagination gap becomes an unplanned item that consumes capacity in a later iteration. That cost is the appraisal failure the cost-of-quality model predicts, and it is far larger than the review that would have caught it.

Common mistakes

  • A definition of done that only says "works". It must name the verification and its evidence.
  • Testing deferred to a phase. If completion does not include verification, the project accumulates unverified work, and the end date becomes unknowable.
  • Confusing done with released. Blurring them either blocks delivery on business timing or pushes unreviewed work out to users.
  • Carrying part-done work silently. This hides slippage and inflates apparent velocity.
  • Team-specific exemptions for "small" items. The small items are the ones nobody reviews, and they are where regressions live.
  • Standards raised with no capacity. A tighter definition of done without adjusting commitments is a decision to miss dates.