Distinctions
| Dimension | Definition of Done | Acceptance Criteria |
|---|---|---|
| Core question | Is this work complete enough to rely on? | Does this story/request satisfy the stakeholder’s expected outcome? |
| Scope | Applies broadly across work items | Applies specifically to one story, request, or deliverable |
| Owner | Usually owned by the team or organization | Usually shaped by stakeholder, product, and delivery-team alignment |
| Stability | Relatively stable across stories, though it should evolve with learning | Changes from story to story |
| Function | Protects quality, completeness, and release discipline | Defines what correct, accepted, or useful means in this case |
| Failure when confused | Teams treat generic quality checks as enough to satisfy a specific request | Teams treat story-specific changes as mere task work instead of changed commitment |
Boundary
Definition of Done defines the general quality bar for completion.
Acceptance Criteria define the story-specific conditions of satisfaction.
Confusing the two can obscure The Single-Request Illusion: the team may satisfy its generic completion standard while the story-specific Acceptance Criteria are still moving.
Systems
Relationships
| Relationship | Concept | Rationale |
|---|---|---|
| Clarifies | The Single-Request Illusion | Separates generic completion from changes to story-specific acceptance criteria |
| Relates | Definition of Done | One side of the false equivalence |
| Relates | Acceptance Criteria | One side of the false equivalence |
Perspectives
| Stance | Who (Point) | What They See (View) | Optimize For | Insight | Blind Spots |
|---|---|---|---|---|---|
| The Done-Is-Accepted Thinker | Stakeholder or delivery team | If it meets the Definition of Done, it should be accepted | Simplicity and fewer separate agreements | A shared quality bar is useful and should prevent sloppy completion | May collapse general completion quality into story-specific satisfaction |
| The Criteria Splitter | Delivery team, product owner, or analyst | Work can meet the team’s quality bar and still fail the story-specific acceptance criteria | Clear distinction between quality and fit-for-purpose | DoD and AC answer different questions | Can feel pedantic unless the distinction prevents real confusion |
| The Agreement Designer | Shared operating model | DoD protects completion quality; AC protects story-specific alignment | Reliable delivery with explicit acceptance | Separating the two helps expose The Single-Request Illusion when AC changes under a stable story intent | Requires keeping both agreements visible as work evolves |