A standing, project-wide bar that every change must clear before it counts as done. Unlike acceptance criteria, which vary per task and answer "did we build the right thing?", the Definition of Done is the same every time and answers "is this finished to our standard?". Use it as the final gate in planning-and-task-breakdown, incremental-implementation, and shipping-and-launch.
| Acceptance Criteria | Definition of Done | |
|---|---|---|
| Scope | Specific to one task or spec | Applies to every increment |
| Changes | Different for each item | Fixed and reused |
| Answers | "Did we build this thing?" | "Is it ready?" |
| Owner | Defined when planning the task | Defined once for the project |
| Example | "User can reset password via email link" | "Tests pass, no regressions, docs updated" |
The two are complementary. A task is done only when its acceptance criteria are met and the standing Definition of Done is satisfied. Skipping either leaves work that looks finished but is not.
Apply this to every change before declaring it done.
- All acceptance criteria for the task are met
- Code runs and behaves as intended, verified at runtime, not just compiled or typechecked
- New behavior is covered by tests that fail without the change and pass with it
- Existing tests still pass; no regressions introduced
- Edge cases and error paths are handled, not just the happy path
- Code reveals intent through naming and structure; no comments needed to explain what it does
- No duplicated business logic
- No dead code, debug output, or commented-out blocks left behind
- Changes are scoped to the task; no unrelated refactors snuck in
- Linting and formatting pass
The depth behind these items lives in code-review-and-quality (the five-axis review) and code-simplification (reducing complexity without changing behavior).
- Change works with the rest of the system, not just in isolation
- Database migrations, config changes, and feature flags are accounted for
- Backward compatibility considered for any public interface or API change
- Public interfaces, APIs, and user-facing behavior are documented
- Architectural decisions worth preserving are recorded (see
documentation-and-adrs) - Documentation describes the current state in timeless language, not the change history
- Security implications reviewed for any untrusted input, auth, or data handling (see
security-and-hardening) - Observability in place for new critical paths (logs, metrics, traces) (see
observability-and-instrumentation) - Rollback path exists for anything risky (see
shipping-and-launch) - The human has reviewed and approved before merge or deploy
- Per task: confirm the Correctness and Quality sections before checking the task off.
- Per feature: confirm Integration and Documentation before considering the feature complete.
- Per release: the full checklist is the floor;
shipping-and-launchadds the deploy-specific gates on top.
Tailor the list to the project once, then reuse it unchanged. A Definition of Done that is renegotiated every sprint is not a Definition of Done.
- "It's done, I just haven't run it yet": unverified work is not done.
- "Tests pass" used as a synonym for done while docs, regressions, or runtime verification are skipped.
- A different bar applied depending on deadline pressure.
- Acceptance criteria treated as the whole bar, with no standing quality floor.
- "Done" declared before human review on changes that need it.