Definition
Acceptance Criteria
Acceptance criteria are the specific, testable conditions a work item must satisfy to be considered complete and correct. Written before work starts, they define the boundaries of a feature — what it must do, and how you'll know it works — turning a vague request into a checklist everyone agrees on, so 'done' is verifiable rather than a matter of opinion.
Key takeaways
- Acceptance criteria are the specific, testable conditions a work item must satisfy to be considered complete and correct. Written before work starts, they define the boundaries of a feature — what it must do, and how you'll know it works — turning a vague request into a checklist everyone agrees on, so 'done' is verifiable rather than a matter of opinion.
- Where a user story says what a user wants and why, acceptance criteria say exactly when that want is satisfied.
- In Planoda, acceptance criteria live as a checklist on the issue itself, so the conditions for 'correct' travel with the work and can be ticked off before it moves to done.
Where a user story says what a user wants and why, acceptance criteria say exactly when that want is satisfied. They are the contract for a single item: a list of concrete, checkable statements — 'a user with an expired token is redirected to sign-in,' 'an empty search shows the zero-state, not an error' — that anyone can verify by trying. Their job is to remove ambiguity before code is written, when it is cheapest to resolve.
Two common formats dominate. A simple checklist of conditions works for most items. For behavior-heavy work, the Given/When/Then form from behavior-driven development is precise: given some context, when an action happens, then a specific outcome must follow. Either way, good criteria are testable (you can demonstrate pass or fail), scoped to this item, and focused on outcomes rather than implementation.
Acceptance criteria are distinct from a definition of done. Acceptance criteria are specific to one item — what this feature must do. The definition of done is the universal quality bar every item must clear regardless of what it is — reviewed, tested, documented. An item is finished only when both its own criteria and the team's definition of done are met.
In Planoda, acceptance criteria live as a checklist on the issue itself, so the conditions for 'correct' travel with the work and can be ticked off before it moves to done.
Related terms
- User StoryA user story is a short, plain-language description of a feature told from the user's perspective, classically in the form 'As a [role], I want [capability], so that [benefit].' It captures who needs something and why, deliberately leaving the how to the team. Stories keep work framed around user value rather than technical tasks.
- Definition of DoneA definition of done is a shared, explicit checklist of what must be true before any work item counts as complete — code reviewed, tests passing, documentation updated, deployed. It removes ambiguity about the word 'done,' preventing half-finished work from being declared finished and creating a consistent quality bar across the whole team.
- Story Points (Estimation)Story points are a relative, unitless measure of how much effort an issue will take, accounting for complexity and uncertainty rather than raw hours. Teams estimate in points — often using a Fibonacci-like scale — to compare items against each other quickly. Summed across a cycle, points feed velocity and burndown without false precision about clock time.
- EpicAn epic is a large unit of work too big to finish in a single cycle, broken down into smaller related issues that ship incrementally. It groups those child issues under one theme and tracks their combined progress. Epics sit between individual issues and broader projects or initiatives in the planning hierarchy.