Distinctions
Is
| Identity | Explanation |
|---|---|
| Conditions of satisfaction | The concrete conditions a story, change, or deliverable must satisfy to be accepted |
| A shared definition of expected outcome | A way for stakeholders and delivery teams to agree what correct, useful, and complete means for this unit of work |
| A test of understanding | Clear acceptance criteria reveal whether the team and stakeholder are imagining the same result |
| A boundary for task work | Tasks execute against acceptance criteria; changing acceptance criteria changes the story-level commitment |
Is Not
| Other | Why It’s Different |
|---|---|
| Definition of Done | Definition of Done is a broader quality bar that usually applies across work items; acceptance criteria are specific to a story or request. See Definition of Done vs Acceptance Criteria |
| Implementation tasks | Tasks describe how the team will produce the result; acceptance criteria describe what result will be accepted |
| A full requirements document | Acceptance criteria should be enough to guide delivery and validation without pretending every implementation detail is known upfront |
| A substitute for conversation | Acceptance criteria capture alignment, but they are produced through discussion, examples, and clarification |
Boundary
Acceptance Criteria are the story-specific conditions that must be true for the work to be accepted.
If a change alters what would count as accepted, correct, or useful, it is a change to acceptance criteria, not merely a new task.
Systems
Relationships
| Relationship | Concept | Rationale |
|---|---|---|
| Mitigates | The Single-Request Illusion | Makes visible when the story’s scope has changed under a stable business objective |
| Complements | Definition of Done | Acceptance criteria define story-specific success; Definition of Done defines broader quality expectations |
| Distinguished by | Definition of Done vs Acceptance Criteria | Prevents story-specific conditions from being confused with the team’s general quality standard |
| Supported by | Definition of Ready | Work is easier to start responsibly when acceptance criteria are understood well enough to guide delivery |
Perspectives
| Stance | Who (Point) | What They See (View) | Optimize For | Insight | Blind Spots |
|---|---|---|---|---|---|
| The Lightweight Requester | Stakeholder or requester | Acceptance criteria are details inside the story | Keeping the request lightweight and avoiding unnecessary process | Not every detail needs a formal requirements document | May miss that changing acceptance criteria changes what the story means in practice |
| The Contract Keeper | IC or delivery team | Acceptance criteria define what accepted, correct, and useful means for this unit of work | Building and validating against shared expectations | Clear criteria reveal whether the team and stakeholder are imagining the same result | Can over-formalize early discovery if criteria are demanded before the problem is understood |
| The Translation Partner | Shared operating model | Acceptance criteria are the contract for what the story means in practice | Preserving flexibility while making delivery commitments explicit | When acceptance criteria change, the story may still have the same intent, but the delivery commitment has changed | Requires discipline to update criteria when conversations shift the acceptance conditions |