“Definition of done” gets repeated in every scrum book without much engineering meaning. It usually lands as a 12-bullet checklist no one reads after sprint 2.
This post is the engineering version: what a useful definition of done actually contains, what to drop, and how to make it the thing your team uses to decide whether a ticket is shippable — not a compliance ritual.
Why most DoDs become decoration
The standard scrum DoD looks like this:
- Code is written
- Code is reviewed
- Tests are written
- Tests pass
- Documentation is updated
- Demo’d to product owner
- Merged to main
- Deployed to staging
Every team has seen one of these. Every team has also stopped reading it after the third sprint. Why?
Because most of those bullets are either obvious (“code is written” — yes), aspirational (“documentation is updated” — under what definition of “updated”?), or unverifiable in practice (“tests are written” — for which behaviours, at what coverage?).
A DoD that nobody references when deciding whether to merge is dead weight. It’s a wall poster, not a tool.
What a useful DoD does
A working DoD answers exactly one question: does the work meet the bar to be shippable, right now, by anyone on the team?
That’s it. Not “did we follow process.” Not “did we tick boxes.” The DoD is a contract between you and future-you: when this ticket is marked done, can the next person in line trust it?
Three properties make a DoD useful:
- Verifiable in seconds. Each item must be checkable in well under a minute. If “documentation is updated” requires reading three docs and three PRs to verify, it’s too vague.
- Independently failable. Each item must be something a reviewer can independently say “this didn’t happen” about. Nothing handwaved.
- Owned by engineering, not by ceremony. A DoD is not the place where “demo’d to PM” lives. That’s a workflow gate, not a quality gate.
The engineering DoD that works
Here’s the version we recommend. Six items, all verifiable.
1. Tests cover the behaviours that the ticket changed
Not “tests exist.” Not “coverage is X%.” The DoD asks: for every behaviour this ticket added or changed, is there a test that would fail if you reverted that behaviour?
This is the only test bar that matters. Coverage percentages can pass while critical paths are untested. “Tests written” can be technically true while the test asserts nothing meaningful.
If the ticket changed a calculation, there’s a test that fails if you break the calculation. If the ticket added an endpoint, there’s a test that hits it. If it changed an error path, there’s a test for the error.
2. Manual smoke test of the happy path
A human looked at the change in a running environment (dev, staging, or production) and saw the feature work end-to-end. Not via screenshot — via clicking through.
If the change is non-UI, this becomes “the relevant CLI command was run / the relevant API was hit and returned the expected response.”
This catches the class of bugs that pass tests because the test setup is wrong. We’ve all had it: tests green, feature broken, mock didn’t reflect production.
3. No new linter or CI failures
CI green, lints clean, no new warnings. This is the cheapest item to verify (look at GitHub) and the most under-applied. Plenty of teams have a DoD with “CI passes” but allow merging with a flaky test ignored. Don’t.
4. Reviewer named in the PR description has approved
Not “code is reviewed.” That phrase is too vague — code reviewed by whom? With what depth?
Concrete version: the PR description names a reviewer, that reviewer left an approval, and the approval came after the most recent meaningful change. If the author force-pushed a refactor after approval, get re-approval. The cost is small; the cost of skipping is occasionally a very surprising bug.
5. Schema changes are reversible or have a documented rollback
This is the one that prevents 90% of late-night incidents. If the ticket modifies the database schema, the rollback path is written down — either as a down-migration that works, or as a comment in the PR explaining “this is a one-way migration because X, here’s how we recover.”
For non-schema changes this item is N/A. But every team should have it in the list because the cost of a non-reversible bad migration is enormous.
6. The ticket description matches what the PR actually does
Read the ticket. Read the PR. Do they describe the same thing?
This is a check on scope creep more than anything else. If you set out to “fix the tooltip bug” and shipped “fix the tooltip bug + refactored the entire tooltip component + added a new analytics event” — the ticket needs to be split, or the description needs to be updated. Tickets where description and PR diverge are where review effort gets spent on the wrong thing and where regressions sneak in.
What to drop from the standard DoD
Three items that look reasonable but are actually noise.
Drop: “merged to main”
If the ticket isn’t merged, it isn’t done. This bullet is a tautology. Don’t put it on a list.
Drop: “demo’d to PO”
This is a workflow step, not a quality bar. It belongs in your sprint review or planning ritual, not in the DoD. If it’s in the DoD, you’ll have engineers marking tickets done before “demo” because the DoD says merged-to-main is enough. You’re encoding a contradiction.
Drop: “documentation is updated”
In its current vague form, this item is mostly ignored. Replace with two specifics if needed:
- If the change touches a documented public API: the API docs were updated as part of this PR, in the same commit.
- If the change introduces a non-obvious operational behaviour (cron job, new config flag, new external dependency): there’s a one-paragraph note in the runbook or relevant README.
If neither applies, this item is N/A. Don’t make it a permanent checkbox you’re checking “yes” on out of habit.
Making it visible
The DoD only works if it’s next to the work. Three places we’ve seen it work, in rough order of effectiveness:
- Pinned to the top of the issue tracker’s ticket template. Every new ticket renders the DoD checklist. Engineers tick boxes as they go. Reviewers can spot-check.
- A bot comment on every PR that lists the DoD items and asks the author to tick each one (or mark N/A). 30 seconds for the author, much faster than memory for the reviewer.
- A pinned message in the engineering channel. Lowest friction, highest decay. Use this only as a backup.
We support the first two natively in SprintFlint — there’s a Definition of Done checklist template that drops into ticket descriptions, and the platform’s PR-link integration shows the DoD inline next to the GitHub link.
The 6-item version vs the 12-item version
Why 6 items, not 12?
Because every additional item dilutes the rest. A 12-item DoD turns into a 12-item ritual. A 6-item DoD that’s actually used catches more bugs than a 20-item DoD that’s ignored.
The bar for “should this be in the DoD” is: if this item is missing, would I reject the PR? If the answer is “probably not, I’d just leave a comment” — it’s not a DoD item, it’s a code review preference.
How to introduce it without ceremony
If your team currently has no DoD, or has one no one reads:
- Sprint 1: agree on the 6 items, put them in a doc. Don’t enforce. Just have them.
- Sprint 2: add them as a checklist on the ticket template. Engineers self-rate, reviewers spot-check.
- Sprint 3: in retro, ask: “in the last sprint, was a ticket marked done that shouldn’t have been?” If yes, which DoD item failed? Tighten enforcement on that item only.
- Sprint 4: by now the DoD has a local meaning. It’s not borrowed from a book.
Don’t try to roll out a heavy DoD by edict. They die. The 6-item version is light enough to land without resistance.
What “done” should feel like
For your team, after 4–6 sprints of running this:
- “Done” means you’d put this in front of a customer right now. No surprises.
- A reviewer can clear a PR in 5 minutes because the DoD did most of the work.
- A new hire can look at a closed ticket and trust it.
- “Done-done” disappears from your vocabulary, because “done” already means done.
That’s the whole point. A DoD isn’t paperwork. It’s the contract that lets engineering velocity stay sustainable.
SprintFlint ships with native DoD checklists, ticket templates, and PR integrations — built for teams who want the contract, not the paperwork. £5/user/month flat. Start free — 300 tickets, no card.