Writing a Definition of Done That Actually Stops Work From Leaking
In Scrum, the Definition of Done is the shared understanding of what it means for work on the Increment to be complete. The Scrum Guide is blunt about why it matters: if an item does not meet the Definition of Done, it cannot be released and is not part of the Increment. So a weak Definition of Done is not a documentation problem. It is a quality leak that ships unfinished work under the label "done."
Many teams write one anyway that says little more than "code complete and tested." When the team was in one room, the gaps got caught at the desk next door. With teams scattered across home offices in early 2021, those informal catches disappeared, and a Definition of Done with teeth became the thing holding quality together. Here is how to write one that does.
Make every line verifiable
A Definition of Done is only useful if any Developer can look at an item and answer yes or no without debate. Replace adjectives with checks.
Instead of "well tested," state the bar: unit tests written and passing, the agreed coverage target met, and the build green.
Instead of "reviewed," state who and how: peer code review completed and comments resolved.
Instead of "documented," name the artifact: the user-facing change note and any API change recorded.
Include the non-functional work that always gets skipped: accessibility, security checks, and performance within the agreed threshold.
Confirm the work is integrated and deployable to the target environment, not merely passing on a laptop.
Build it, own it, and tighten it over time
The Definition of Done belongs to the Developers, not to a manager handing down a checklist. Build it together so the team will actually enforce it, then treat it as a living standard.
Draft it with the whole team. Run a session where Developers list every step that has bitten them before. Shared authorship is what turns a checklist into a commitment people defend.
Respect organizational standards. If your organization has a broader Definition of Done, yours must meet or exceed it. The team can add stricter criteria, never weaker ones.
Apply it during the Sprint, not at the end. Items move toward Done continuously. Treating it as a final gate produces a pile of nearly-done work that fails inspection at Sprint Review.
Inspect and adapt it in the Retrospective. When a defect slips through, ask which line of the Definition of Done would have caught it, and add that line. The definition should get stronger as the team learns.
A real Definition of Done changes the tone of every conversation. "Is it done?" stops being a judgment call and becomes a checklist anyone can run. Velocity may dip at first as hidden work becomes visible, but what you ship is genuinely shippable, and that is the only kind of progress worth counting. For a remote team, that shared, explicit standard is often the difference between transparency and quiet drift.
If your teams need delivery standards that make "done" mean the same thing everywhere, XNM's program & project delivery advisory can help you define and embed them.