A definition of done that can be checked

Goal

Replace subjective "done" with a shared, verifiable checklist so that work is either complete or visibly not.

Prerequisites

A team that produces increments (features, fixes, releases) and a place where the checklist is visible to everyone.

Steps

1. List the conditions that currently, in practice, cause work to bounce back: missing tests, missing documentation, not deployed, not reviewed.
2. Rewrite each condition so that it can be answered yes or no by looking at an artifact: "pipeline green on the merged commit", "changelog entry present", "feature flag documented".
3. Keep the list short; if a condition is never the reason work bounces, remove it.
4. Apply the list at review time, not at the end of an iteration; the reviewer checks it explicitly.
5. Revise the list when a failure escapes, adding the check that would have caught it.

Expected result

Fewer items that are "done except for …"; reviewers and authors agree on completeness without discussion; the checklist encodes past lessons.

Limits and test basis

The Scrum Guide describes the Definition of Done as a formal commitment for increments; the specific conditions are the team's to define. A checklist cannot judge whether the work was worth doing.