Teams argue about "done" not because they lack a Definition of Done, but because the one they have is documented, not checkable — a paragraph of prose nobody re-reads, instead of a gate the work has to pass. Ending the argument means turning DoD from something people are supposed to remember into something the workflow itself enforces.
Quick Answer: "Done" fights happen when a Definition of Done is written but not enforced — vague enough that two honest people can disagree in good faith. Fix it by writing every criterion so a non-author can verify it without asking a follow-up question, then attaching it to the step where work actually moves forward.
What Definition of Done Actually Means (and Why the Checklist Isn't the Problem)
A Definition of Done (DoD) is a team's standing done criteria — a shared checklist a piece of work must clear before anyone calls it finished, not the acceptance criteria for one specific story and not a synonym for "merged." The Scrum Guide treats it as a formal quality standard the whole team owns collectively, not a call any one person gets to make alone.
That's the textbook version, and most teams can recite something close to it in a retro. The actual argument almost never starts there. It starts when two reasonable people look at the same finished-looking piece of work and reach opposite verdicts, each one convinced they're applying the same standard the other person is.
DoD and acceptance criteria aren't the same instrument, and conflating them is its own source of arguments:
| Acceptance criteria | Definition of Done | |
|---|---|---|
| Scope | One specific story | Every story, regardless of which one |
| Answers | "What does correct look like here?" | "What do we always require before shipping?" |
| Written by | Whoever wrote the story | The team, once, and reused |
Confuse the two and teams either duplicate the same checks twice, or wrongly assume covering one automatically covers the other.
None of that explains why the arguments actually happen, though, because the content of a DoD is rarely what's in dispute. What's in dispute is whether it's real — whether it's a completion agreement the whole team is actually bound by, or a document that exists in case someone asks.
Five Signs Your Definition of Done Is Still Implicit
A written DoD can still function as an unwritten one if nobody has to check it. Watch for these tells:
- Nobody can point to where it's checked — it exists as prose, not as a step in any workflow
- It hasn't been opened or edited in months, despite dozens of stories shipping since
- Different people in the same retro can describe different versions of it
- It only gets cited when someone wants to block a release, never during normal work
- "Done" gets renegotiated out loud, in the room, under deadline pressure
The Real Reason Teams Argue: Implicit Rules, Not Missing Ones
Most teams that fight over "done" already have a Definition of Done — it just lives as tribal knowledge, a private mental copy each person carries and quietly edits. The argument isn't a missing-rule problem; it's an implicit-rule problem, and rewriting the wiki page doesn't fix a rule nobody has to check against before moving on.
It helps to see this as three rungs of a ladder, not a binary of "has a DoD" versus "doesn't." Most teams assume they're standing on the top rung. Most are actually on the bottom one, with a middle-rung document nobody consults:
| Level | What it actually looks like | Where the argument surfaces | Typical failure |
|---|---|---|---|
| 1. Implicit | "Done" lives in a few people's heads and shifts depending on who's asked | A heated Slack thread mid-sprint, or a retro | New hires and stakeholders get a different answer every time |
| 2. Documented | A checklist exists — in a wiki, a ticket template, a handbook | Sprint review or release day, once someone finally rereads it | Nobody re-checks it once a story looks "basically finished" |
| 3. Checkable | Every criterion has a verifier — a test, a scan, a required field — wired into the workflow itself | Rarely; the gap gets caught before it reaches a person | Almost none; the residual risk is a broken check, not a disagreement |
Rung two feels like progress — there's a document now — but a document nobody has to consult before moving work forward behaves exactly like rung one the moment a deadline gets tight. Rung three is the only level where "done" stops depending on who happens to be in the room that day.
A Definition of Done nobody has to check isn't a definition. It's an opinion with better formatting.
This is close to what Jeff Sutherland, Scrum's co-creator, has long described as "undone work" — the testing, integration, and documentation that a weak DoD lets slide, which doesn't vanish but resurfaces later as a costly, unplanned hardening pass before release. A checklist that isn't enforced doesn't prevent that work — it just defers it, with interest.
Making that shift — from implicit agreement to explicit, checkable rule — is the same discipline that separates agile product management from ceremony-running: turning a team's unwritten agreements about readiness, scope, and done into something anyone can check, not just whoever's been on the team the longest.
The Five Arguments Every Team Has About "Done"
Nearly every "is this done" fight is a variation on five recurring patterns: scope quietly expanding mid-review, QA and engineering applying different bars, a stakeholder adding an unwritten criterion, "done" meaning "merged" instead of "verified," or no fixed version of DoD to check against. Naming the pattern resolves the fight faster than re-litigating the ticket.
Laid out side by side, the repetition — and the fix — becomes obvious:
| Dispute | What it sounds like | Root cause | The checkable fix |
|---|---|---|---|
| Scope creep disguised as "almost done" | "It's done except for the error states" | DoD never named which states are in scope | List the exact states and inputs covered — not "handles errors" |
| QA vs. engineering standoff | "Works on my machine" / "Fails on this input" | No shared, versioned test both sides actually run | Attach the real test or script to the ticket, not a description of one |
| The demo-day surprise | "Shouldn't this also do X?" | A stakeholder's implicit criterion was never on the DoD | Route new criteria into the backlog, not into the current release |
| "Code complete" wearing "done" | "It's merged, so it's done" | DoD stops at merge instead of verified-in-use | Require a monitoring signal or usage check before close |
| No canonical version | Two people quote two different checklists | DoD isn't versioned or centrally linked | One editable, linked source per team — never a copy pasted per ticket |
Four of these five root causes are the same defect in different clothes: a criterion existed only as an assumption, never written where the disagreement could be caught before it became one.
Picture a "done" self-serve CSV export. Engineering ships it, tests pass, the ticket closes without incident. Two weeks later a customer exports 40,000 rows and the browser tab freezes — nobody had put a row-count boundary in "done," because "it exports the data" felt complete enough to close. The story wasn't wrong. The DoD never asked the question.
That gap shows up in delivery data, not just anecdotes. Google Cloud's long-running DORA research on software delivery has repeatedly found that teams verifying changes rigorously before release carry change-failure rates several times lower than teams that don't — a pattern that lines up exactly with what a shallow, unenforced DoD predicts.
How to Turn a Documented Definition of Done Into a Checkable One
A DoD line is checkable when someone who didn't write it — a teammate, a reviewer, ideally a machine — can verify it's true without asking the author a follow-up question. Replace adjectives like "tested" or "accessible" with a named artifact anyone can go look at: a passing test, a scan result, a linked document.
Most DoD lines fail this test not because they're wrong, but because they were written as intentions instead of artifacts. Rewriting a handful fixes most of the ambiguity:
| Written as (vague) | Rewritten as (checkable) |
|---|---|
| "Tested" | Automated tests cover the documented edge cases; CI is green on the PR |
| "Works well" / "Handles errors" | Passes the specific, named error-state list attached to the ticket |
| "Documented" | Changelog entry and help-doc update merged in the same PR, not a follow-up |
| "Accessible" | Passes an automated a11y scan plus a logged manual keyboard-navigation check |
| "Won't break anything" | Feature flag and rollback path exist; a monitoring alert is configured pre-release |
Every entry in the right-hand column answers "checkable by whom, using what" — exactly the information the left-hand column leaves for someone to assume. Assumptions are where "done" arguments are born.
Extreme Programming, the methodology Kent Beck formalized in the late 1990s, leaned hard on this same idea: a passing automated test suite is about as close to an objective, checkable definition of done as software gets, because it doesn't depend on whose judgment happens to be in the room. You don't need to run XP to borrow the principle — prefer criteria a tool can verify over criteria a person has to vouch for.
Three Edits That Make Any DoD Line Checkable
- Swap the adjective for an artifact. "Tested" becomes a link to a passing test run, not a claim someone makes.
- Name the verifier. A specific role, tool, or automated check — never "the team," which really means no one in particular.
- Attach it to the step where work would move forward anyway. A PR merge, a ticket transition, a release checklist — so skipping it means overriding a visible gate, not just staying quiet.
One more upgrade worth making: anchor at least a few DoD lines to the underlying job a story serves, not just the tasks it completes. A feature can clear every technical box and still miss the actual job the customer hired it to do — a different, and often harder, failure to catch than a missing test.
The cheapest place to catch a DoD gap is before the story is even built. A backlog item that's genuinely groomed for clarity rather than just sorted into order already carries most of what a checkable DoD line needs — named edge cases, a stated job, a testable outcome — because refinement forced the ambiguity out early, while it was still cheap to fix.
Where Definition of Done Should Live (Not a Wiki Page No One Opens)
A checkable DoD has to live at the exact point where work is about to move forward — attached to the ticket, the pull request, or the spec — not filed in a separate document someone has to remember to open. If checking it takes an extra click to a different tool, it gets skipped exactly when it matters most: under deadline pressure.
Ownership ambiguity makes this worse. The Scrum Guide assigns quality standards to the whole Scrum Team, but few companies run a textbook Scrum Team — most run something with a PM bolted on, and what the guide says about that role rarely matches what actually happens day to day. When nobody is unambiguously accountable for enforcing DoD, everyone assumes someone else already checked it.
If nobody can point to where "done" actually gets checked, it isn't a Definition of Done. It's a hope with a heading.
Where the arguments actually surface is diagnostic. A "done" dispute that keeps erupting during sprint review, or one that drags sprint planning past the point where it's still useful, is usually a sign the DoD lives somewhere nobody consults before committing to the work — not a sign the team needs a longer meeting.
DoD also has to reach past the ticket's own edges. A change can clear every technical line item and still fail the user if it lands at the wrong moment — tested in isolation, never checked against the actual point in the customer's journey it's supposed to improve. "Verified against the real moment it's meant to help" is a DoD line most checklists skip entirely.
Turning "Done" Into a Gate: Where Prodinja's Spec Studio Fits
The mechanism that actually ends "is it done" arguments is a gate the work can't pass silently, not a better-written paragraph. Prodinja's Spec Studio is built around that idea: it lets you attach readiness gates — a definition of ready, a definition of done, or both — directly to a section of the spec, so a story can't move forward while a gate is failing.
That's a direct answer to the documented-versus-checkable gap this whole article has been circling. A gate isn't prose someone has to remember to reread — it's a condition the spec itself carries, visible to engineering and product alike, and surfaced again in every PR-style diff whenever the spec changes. It doesn't replace the judgment call about what "done" should mean for your team. It just stops that judgment from quietly depending on who happens to be reviewing the ticket that day.
Whatever tool ends up encoding it, the underlying discipline stays the same: implicit doesn't survive deadline pressure, documented barely does, and checkable is the only version that holds.
Key Takeaways
- Most "done" arguments are implicit-rule problems, not missing-rule problems. A
DoDthat lives as tribal knowledge or unread prose behaves the same as having none once deadline pressure hits. - There are three rungs of
DoDmaturity — implicit, documented, checkable. Only the third stops "done" from depending on who's in the room. - Nearly every done-dispute is one of five recurring patterns: scope creep, QA/engineering mismatch, a late-added stakeholder criterion, "merged" mistaken for "verified," or no canonical checklist version.
- A
DoDline is checkable when a non-author can verify it without asking a question. Replace adjectives with named artifacts a test, scan, or document can prove. DoDhas to live where work actually moves forward — the ticket, PR, or spec — not a wiki page nobody opens before shipping.- Ownership has to be unambiguous, or everyone assumes someone else is checking it, and no one actually is.
- A checkable
DoDis a gate, not a memory exercise — the goal is a condition the workflow enforces, not a document someone has to remember to reread.
Frequently Asked Questions
What is Definition of Done in Agile?
Definition of Done (DoD) is a shared, standing set of done criteria a piece of work must satisfy before a team calls it finished — covering things like testing, review, documentation, and monitoring, regardless of which specific story it is. The Scrum Guide treats it as a formal quality standard the whole Scrum Team owns collectively, not a suggestion any one person can waive.
Who decides when something is really done?
Nobody should decide it alone — that's the entire point of having a DoD in the first place, so the checklist decides and people just check it. In practice, engineering typically confirms the technical criteria while product confirms the criteria tied to user value, and neither side can unilaterally override a criterion the other owns.
Can Definition of Done change during a sprint?
It shouldn't change mid-sprint for work already in flight — that's a bait-and-switch on whoever's building it against the original agreement. It can and should evolve between sprints as the team learns what it missed, which is why DoD needs to be a living, versioned document instead of something written once and left untouched for a year.
What's the difference between "code complete" and actually done?
"Code complete" means an engineer stopped typing and the change merged; "done" means the work was tested, reviewed, documented, and verified to behave correctly under something close to real conditions. Treating the two as synonyms is one of the most common ways a weak DoD lets unfinished work quietly ship as finished.
How do you enforce Definition of Done without adding bureaucracy?
Enforce it with gates wired into the workflow itself, not with an extra meeting or a manual sign-off — automated checks and required fields don't resent being consulted. The "bureaucracy" complaint almost always means the enforcement mechanism is a person interrupting other people's work, instead of a condition already built into the tool everyone's using.