~i: Inspect — SCRUM Definition of Done
The single gate that prevents incomplete work from being called "done"
What It Is
"A formal description of the state of the Increment when it meets the quality measures required for the product. Once the Definition of Done is met, the Increment is Done and can be delivered."
— 2020 Scrum Guide
The DoD is a non-negotiable quality gate. Work that doesn't pass every item on the checklist is not Done. Not "mostly done." Not "done except for." Not Done. It goes back to the backlog.
The Gate Mechanism
- Work is developed
- Each DoD criterion is checked
- If ALL pass → work is "Done" and counts as part of the Increment
- If ANY fails → work is "Not Done" — returns to backlog
- Only Done work can be presented, shipped, or counted as progress
This is binary. There is no partial credit.
DoD vs Acceptance Criteria
| Aspect | Definition of Done | Acceptance Criteria |
|---|
| Scope | Applied to every work item | Specific to individual items |
| Focus | How it's done (quality) | What must work (function) |
| Stability | Same across all work | Changes per item |
| Content | Testing, commits, docs, deploy | Expected behavior |
Both must be satisfied. A feature that works but wasn't tested/committed/shipped properly is not Done.
Why It Prevents Work Loss
- Prevents false completion. You can't say "done" when telemetry has null commit hashes, when the chain didn't ship, when the board wasn't updated. The DoD catches it.
- Prevents rework. Quality checks happen at the gate, not after shipping. No "fix it later."
- Creates transparency. Everyone — including the next Claude Code session — can verify what's actually done by checking the DoD criteria.
- Embeds quality in workflow. Testing, commits, telemetry aren't optional afterthoughts. They're prerequisites for "Done."
- The Increment is additive. Each Done item builds on all prior Done items. The DoD guarantees they still work together.
How This Maps to Be's Problem
Be currently has no DoD. The chain reaction defines steps (build → report → telemetry → commit → push) but doesn't gate on them. If a step is skipped, work is still called "done." Evidence:
- 14 builds, 6 ships — the build step ran but the ship gate was never enforced
- 9/11 null commit hashes — telemetry step ran but the hash backfill was never enforced
- Board items moved to Done without commit references — no way to verify
- Next session has no way to distinguish "Done and verified" from "Done but incomplete"
The chain reaction is a workflow. A DoD is a gate. Be has the workflow. It's missing the gate.
The Key Insight
The 5-guard plan from the previous ~P proposed scattered tactics: pre-flight checklist, stewardship rule, chain completion flag, source-of-truth declaration, Done-means-Done board rule. These are all symptoms of a missing DoD.
A single Definition of Done — enforced as a gate after every work command — replaces guards 3, 4, and 5 entirely. Guards 1 and 2 survive as a Definition of Ready (pre-condition) and a project convention (source of truth), respectively.
One gate. Not five.
Open Questions
- Should the DoD be defined per-project (in project CLAUDE.md) or globally (in metal CLAUDE.md)?
- Should there also be a Definition of Ready (pre-flight) or is the DoD alone sufficient?
- How strict? Fail on ANY missing criterion, or warn-and-continue for non-critical items?
- Should the DoD checklist be rendered into every build report as a visible audit trail?