Write a Definition of Done You Can Meet Today

When is the laundry done? When the machine stops? When it is dry? When it is folded? When it is in the drawer?

Every household has an unwritten answer, and every argument about laundry is really an argument about which answer people were using. Nobody was lazy. They had different definitions.

Now put that argument inside a team, with money and a customer attached. Your team says the feature is finished. Testing says it is not. The Product Owner thought it included the help article. The compliance officer thought it included the audit log. Six weeks later somebody's name is on a slide about why the release slipped.

That is not a discipline problem. It is a definition problem, and Scrum solves it with one written artifact: the Definition of Done.

Here is the part most teams get wrong on the first attempt, and it is the reason I would rather you write six honest lines than sixteen impressive ones. A Definition of Done describes the highest standard your team can actually meet today. Not the standard you wish you held. Not the one that would look good if a director wandered past the board. An aspirational Definition of Done does not raise your quality. It teaches your team that the document is decorative, and a decorative standard is worse than no standard at all.

The point is not quality. It is making "done" mean something.

The misunderstanding to name first is that this is paperwork — a checklist a mature team eventually outgrows. The opposite is true.

The Definition of Done is the only thing standing between your team and the most expensive failure mode in knowledge work: undone work, which is work that has been counted as complete and is not.

Undone work is dangerous because it is invisible and it compounds. Each Sprint the team declares eight items done, and each Sprint a small amount of testing, documentation, integration, or review quietly does not happen. Nothing looks wrong. Velocity looks strong. Then the release date arrives and eight Sprints of small omissions have become a three-week block of unplanned work that nobody estimated and nobody scheduled.

Teams have names for that block. A testing phase. Hardening. A stabilization Sprint. Those are all names for a debt accumulated in plain sight because "done" was never written down.

The second job of the artifact is transparency. When a Product Owner hears that six items are done, that word has to mean something specific or the number is worthless. In the 2020 Scrum Guide the Definition of Done is a commitment attached to the Increment — one of three, alongside the Product Goal for the Product Backlog and the Sprint Goal for the Sprint Backlog. Calling it a commitment says something precise. It is not a target the team aims at and sometimes misses. It is the standard that makes the Increment what it claims to be.

Two boundaries keep it clear. The Definition of Done applies to every item; acceptance criteria apply to one. "Password reset email arrives within sixty seconds" is an acceptance criterion for a single story. "Reviewed and approved by one person who did not write it" belongs to everything the team builds. Confusing the two is the most common early mistake.

The other boundary is between done and released. Done means the work meets the standard and could be released. The Product Owner decides whether to release it. A Definition of Done that says an item is only done once it has shipped to customers ties your team's ability to finish work to a business decision that is not theirs to make.

An aspirational Definition of Done does real harm

Here is what happens when a team writes the version it wishes were true.

Sprint one, three items miss two of the twelve lines. The team calls them done anyway, because the Sprint has to close and everyone knows those lines were ambitious. Sprint two, the same thing, faster, with less discussion. By Sprint five the document has stopped describing the team's behavior and has become a wall poster.

The team has now learned something worse than a low standard: it has learned that written standards are negotiable under pressure. When you later try to add a line that genuinely matters — a security review, an accessibility check, a control that a regulator will ask about — the team has no muscle for treating a line as non-negotiable, because it has been ignoring lines for months.

There is a specific version of this that goes badly. Picture a claims platform team two days from the end of a Sprint with three items stuck in security review. Someone proposes that security review move to "post-Sprint follow-up," just this once, so the items can count. It is clearly a formality. Everyone agrees. Four Sprints later a dozen items are carrying deferred security review, one of them has a real flaw, and the remediation takes weeks.

Nobody in that room was careless. They changed the definition by one line, once, under time pressure — which is precisely the moment the definition exists to survive.

A true Definition of Done gets stronger. An aspirational one gets ignored, and ignoring it is a habit that transfers.

Write the honest version in forty-five minutes, in five moves

Get the whole Scrum Team in one room. Give it forty-five minutes. Aim for six to twelve lines.

Move one: list what already happens. Ask the Developers what they actually do to every item before they consider it finished, and write it down without editing. You will get six to ten items, and some will be habits nobody knew were shared. This is your honest starting point, and starting honest is what makes the document usable rather than decorative.

Move two: add what the organization requires whether you like it or not. Regulatory checks, security review, accessibility standards, brand approval, records retention. These are non-negotiable, and they are frequently the items that get skipped under pressure, which is exactly why they belong in writing.

Move three: make every line testable. A line a person outside the work cannot check is not a criterion, it is a mood. "Code is clean" fails. "Reviewed and approved by one person who did not write it" passes. Read every line and ask whether a stranger could decide yes or no in under a minute. If not, rewrite it.

Move four: agree it with the Product Owner. That agreement is what gives the Product Owner the right to refuse an item that does not meet the standard, and what protects the team from being asked at the last minute for something outside it.

Move five: post it where the work happens, and treat changes as deliberate. On the wall, on the board, at the top of the ticket template. Then leave it alone during the Sprint. Strengthening it is a normal, healthy Retrospective outcome. Weakening it mid-Sprint to make a date is how teams get into trouble.

One more mechanic worth borrowing. Mark each line with an H if your team already does it every time, and a G if it is a gap you intend to close. Keep both marks. The H lines are your real standard starting Monday. The G lines are your improvement backlog, and they belong in Retrospectives one at a time — not in the document as though they were already true.

What this looks like outside software, because the shape is identical. A marketing team: copy reviewed by a second person, every claim checked against source data with the source linked, assets exported in every required size, tracking verified firing in the live environment. A hardware team: the drawing updated with a revision number, design review signed by mechanical and electrical, the risk file updated, the bill of materials costed. Same pattern. Specific, checkable statements that apply to everything.

The caveat: your standard is capped by your control, and that is fine

Plenty of teams cannot include releasing, because releases go through a separate group four times a year. Are you allowed a weaker Definition of Done? Yes.

A bakery that cannot deliver its own cakes because a courier holds the contract can still finish a cake: baked, decorated, boxed, in the cooler with the ticket on it. What it cannot claim is that the customer has it.

Write your Definition of Done as far as your control reaches — tested, reviewed, documented, approved, packaged, ready to release — and then be precise about that last phrase. Potentially releasable means somebody could release it and nothing further would need to be built. It does not mean it has shipped, and a team that blurs the two is telling itself a story the release date will eventually correct in public.

What matters is what you do with the gap. Write the missing step down where everyone can see it, with a number beside it: the weeks between finished and available to a customer, and the value sitting idle in the meantime. That is not complaining. It is probably the most useful impediment your Scrum Master will ever carry into the organization, and it belongs to the people who own the release process rather than to your team.

Then raise the standard as your control grows. A Definition of Done that has not gained a line in a year is describing a team that stopped improving.

Key takeaways

• A Definition of Done describes the highest standard your team can meet today — not the standard you wish you held.
• Its real job is preventing undone work: work counted as complete that is not, which compounds invisibly until a release date exposes it.
• The Definition of Done applies to every item; acceptance criteria apply to one item. Confusing them is the most common early mistake.
• Every line must be checkable by a stranger in under a minute, or it is a mood rather than a criterion.
• Mark each line H for habit or G for gap. The habits are your standard starting Monday; the gaps belong in Retrospectives, one at a time.

Frequently asked questions

What is a Definition of Done in Scrum?

A Definition of Done is a written list of criteria that every item must meet before anyone can call it done, agreed between the Developers and the Product Owner. In the 2020 Scrum Guide it is a commitment attached to the Increment. Its purpose is to make the word done mean one specific thing, so that a count of finished items is worth something to the Product Owner and the organization.

What is the difference between the Definition of Done and acceptance criteria?

The Definition of Done applies to every item the team builds; acceptance criteria apply to one item only. "All automated tests pass and the change is documented" is a Definition of Done line. "Password reset email arrives within sixty seconds" is an acceptance criterion for a single story. A team needs both, and putting item-specific conditions into the Definition of Done is a common early mistake.

Why is an aspirational Definition of Done harmful?

Because it gets broken immediately, and breaking it becomes a habit. A team that misses lines every Sprint learns that written standards are negotiable under time pressure. Later, when a line that genuinely matters is added — a security review or a regulatory control — the team has no practice at treating a line as non-negotiable. A shorter honest list that the team meets every time is far stronger.

Can a Definition of Done exclude releasing to customers?

Yes. Write the standard as far as your team's control reaches: tested, reviewed, documented, approved, packaged, and ready to release. Potentially releasable means somebody could release it and nothing further would need to be built. Then record the gap between finished and available to customers, with the weeks and the idle value beside it, and raise that as an impediment to whoever owns the release process.

How long should a Definition of Done be?

Six to twelve lines is a good working range for a first version, written by the whole Scrum Team in about forty-five minutes. Start by listing what the Developers already do to every item, add what the organization requires regardless of preference, then rewrite any line a stranger could not verify in under a minute. Length matters far less than whether every line is true today.

Where this goes next

Drafting a Definition of Done for a real team, then auditing that team against it, is Module 6 of Scrum Essentials, beLithe's eight-module self-study class — along with the Sprint time box, the Rules of the Sprint, and what to do when a change arrives mid-Sprint.

See Scrum Essentials