Definition of Done: Minimal vs. Expansive

---

The Question

Every team's Definition of Done sits somewhere on a spectrum. At one end: minimal — three or four hard-line items that every story must meet (code reviewed, tests pass, merged to main). At the other end: expansive — fifteen or twenty items covering performance, accessibility, observability, documentation, security review, and more.

Both ends have defenders. The minimalists argue that a DoD must be a bar the team can hit every time, and that "expansive" definitions become aspirational rather than enforced. The expansionists argue that "done" should mean what it says — fully done — and that a short list lets too much through.

The Case for Minimal

• Enforceability. A short, hard-line DoD is something the team can actually hit on every story. The contract is real.
• Clarity. Three or four items are remembered without checking a wiki. Twenty are not.
• Trust. A DoD that means what it says — "if it's done, it really meets this bar" — is more useful than one that's aspirational.
• Forces real conversations. Items not on the DoD must be discussed per-story instead of being lumped together as "done."

How Minimal Fails

• Quality details fall through. If accessibility isn't on the DoD, stories ship inaccessible. Repeatedly.
• Inconsistency across stories. Some stories get the extra treatment; others don't. The team produces variable quality without realizing it.
• Standards rot. Things the team used to do (performance testing, security review) gradually drop because they aren't enforced.

The Case for Expansive

• Comprehensive quality. All the dimensions of "really done" are explicitly enforced.
• Consistency. Every story gets the same treatment; no quality dimension is accidentally skipped.
• Forces discipline upstream. Knowing the DoD includes accessibility forces the team to think about it during design, not at the end.
• Documentation of standards. The DoD becomes a record of what "we do" looks like.

How Expansive Fails

• Aspirational, not enforced. The team can't actually hit every item every time, so the DoD becomes a wishlist.
• Compliance theatre. The team ticks boxes without doing the underlying work. The DoD becomes paperwork.
• Bottleneck creation. Some items (security review, formal accessibility audit) take days. Including them in DoD effectively halts the team waiting for them.
• "Story not done" becomes routine. If 30% of stories miss DoD, the bar has lost its meaning.

The Honest Position

The DoD should sit at the boundary of what the team can actually do on every story. Items that pass that test belong on the DoD; items that don't belong somewhere else — perhaps as part of release-level checklists, or epic-level acceptance, or as standards that get spot-checked.

A useful three-tier model:

• DoD (per-story): the bar every story must meet, hard-enforced. Short, achievable, observable.
• Definition of Awesome (aspirational): the qualities the team would love to embody on every story. Used during refinement to inform design choices but not enforced as a gate. See Definition of Awesome.
• Release readiness checklist: the additional bar for things going out the door — security review, accessibility audit, performance benchmark. Applied to the increment, not the story.

The Drift Pattern

Most teams oscillate. They start with a minimal DoD, gradually add items as they discover gaps, and end up with an aspirational expansive one. Then someone notices it's not being enforced, and the team prunes back to minimal — losing the standards they had quietly maintained. Avoiding this oscillation requires either:

• Discipline to enforce expansive DoD (rare).
• Or the three-tier model above, where each layer earns its enforcement.

Coaching Tips

Audit DoD compliance.

What percentage of stories actually meet every DoD item? If it's less than 90%, the DoD is aspirational, not enforced.

Move aspirations to Definition of Awesome.

Items the team values but can't always hit belong there, not on DoD. The separation keeps both lists honest.

Use release checklists for integration work.

Security review, formal a11y audits, performance benchmarks live in release readiness, not story DoD. Cleaner separation, less story-level theatre.

Watch the rotting pattern.

Standards the team used to maintain that drop off the DoD often quietly rot. Make the removal explicit, or move it to another tier.

Test items for observability.

"Documentation is complete" — by whose standard? Items must be observable to be enforceable. Vague items create compliance theatre.

Revisit DoD every quarter.

The team's capability grows. What was aspirational six months ago may now be routinely achievable. Promote items deliberately.

Summary

The Definition of Done debate is about how much weight a single artifact should carry. Stuffing every aspiration into the DoD produces an unenforceable wishlist. Stripping it to the minimum produces a bar that's met but doesn't actually represent what the team values. The healthiest stance is to keep the DoD as a tight, enforceable contract, separate the aspirational into a Definition of Awesome, and use a release readiness checklist for the integration-level work that doesn't fit either. Three artifacts, each doing its own job, none pretending to do another's.

Back to The Great Agile Debates