Somewhere in your company's Confluence instance, there's a page called "Definition of Done." Last edited fourteen months ago. Eight to fifteen bullet points. At least three reference Jira. Every one designed to be verifiable by someone who doesn't understand what the software actually does.
That's not a quality standard. It's a treaty—a liability shield negotiated between engineering, product, and management that says: when things go wrong, here's how we prove it wasn't our fault.
What Your DoD Items Actually Mean
| What the DoD Says | What Actually Happens |
|---|---|
| Code reviewed by at least one peer | Someone clicked Approve. The review took between 90 seconds and 4 minutes. Nobody ran the branch locally. |
| Unit tests written and passing | A happy-path test was written. The edge case that causes a production incident in three weeks remains untested. |
| Acceptance criteria met | The PO squinted at a screen for thirty seconds and said "looks good." |
| No critical or high-severity bugs | The bugs were reclassified as "medium" so the story could close. |
| Deployed to staging | Deployed to a staging environment that doesn't resemble production. |
Every item is optimized for one thing: can we check a box in Jira?
Why Nobody Fixes It
Everyone knows the DoD is theater. Fixing it would require making it actually rigorous — and rigorous means stories take longer, velocity drops, and someone tells a VP the team will deliver less.
Throughput is what gets measured and rewarded. So the DoD stays weak. It's a negotiated settlement, not a quality standard.
The DoD Negotiation
New engineering director proposes load testing, integration tests in production-like environments, security reviews, canary bake periods. Reasonable items that actually prevent incidents.
Within a month, every new item is quietly dropped or made optional. The DoD returns to its previous state: a list of things verifiable by looking at Jira metadata.
The lesson: the DoD is a political agreement. Changing it requires changing incentives, delivery expectations, and management culture. You can't just edit a wiki page.
A DoD That Actually Worked
Small B2B SaaS. Three outages, two lost contracts. The CTO replaced the DoD with one rule:
"A story is Done when the engineer who built it would deploy it at 4:55 PM on a Friday without telling anyone, and sleep soundly."
It worked because: permission to slow down, velocity removed as a metric, adversarial peer review, and social accountability replaced checkboxes. Customer incidents dropped around 80% in two quarters.
Cost: 30% delivery reduction, executive air cover, total metric overhaul. Most organizations won't pay it.
Auditing Your DoD
- Friday Deploy Test: Does each item increase production confidence, or just prove someone did something?
- Last Incident Autopsy: Was the DoD satisfied on the story that caused your last three incidents?
- Timing Test: If code reviews average under ten minutes for 500+ lines, it's a rubber stamp.
- Rigor Conversation: Propose one hard item. Watch the velocity objections surface.
- Uncomfortable Question: When did the DoD last actually block a story?
The Root Cause
The Agile-industrial complex built a framework where visible throughput is the primary success metric, then told teams to also care about quality. The DoD is where that tension collapses into theater.
Stop editing the document. Start changing the system that made it necessary.
Originally published at agilelie.com.
Top comments (0)