What is Acceptance criteria?
By Heemang Parmar · Updated July 2026 · Editorial policy
Acceptance criteria are the specific, testable conditions a feature must satisfy before it counts as complete, giving engineers, testers, and AI agents a shared, verifiable definition of done for each user story or requirement.
Acceptance criteria translate intent into checks anyone can verify: "the form rejects invalid emails," "the export completes in under 10 seconds." Two formats dominate: plain checklists, and the Given/When/Then structure from behavior-driven development, which states the starting condition, the action, and the expected result. Either format works; the test is whether a stranger could run the checks without asking a single clarifying question.
In practice, acceptance criteria are where most scope disputes get settled before they start. A story like "users can reset their password" hides a dozen decisions: does the link expire, what happens on a second click, is the old session invalidated? Writing the criteria forces those answers early, when changing them costs nothing.
They matter even more when an AI is doing the building. A coding agent given "add search" will make its own assumptions; given five concrete criteria, it has a checklist to build against and a way to self-verify. Clear criteria are the difference between reviewing output and re-specifying it.
Why does acceptance criteria matter?
Acceptance criteria matter because they are the cheapest quality assurance a team can buy. A criterion written before the build costs one sentence; the same gap found after launch costs a bug report, a fix, and a release. They also settle the perennial "is it done?" argument with a checklist instead of an opinion, which shortens reviews and standups alike. Teams that write criteria up front also hand QA a ready-made test plan instead of asking testers to reverse-engineer intent from the interface.
For AI-assisted teams, criteria have become the human's highest-leverage contribution. Agents can generate code and even tests, but they cannot infer business rules, compliance constraints, or edge-case policy; criteria are where that judgment gets encoded. They also translate directly into automated tests, so QA verifies the product against the spec rather than against whatever got built.
How does acceptance criteria work?
- 1Start from the story: Derive each criterion from the story's goal, so every check protects a piece of user value rather than an implementation detail.
- 2Make each one testable: Write binary pass-or-fail conditions with numbers where they matter: "completes in under 10 seconds," not "feels fast."
- 3Cover the edge cases: Spell out empty states, errors, permissions, and repeat actions, since these gaps are where most post-launch bugs hide.
- 4Agree before building: Review criteria with engineering, or hand them to the agent, before work starts; anything added later is a scope change.
Acceptance criteria vs definition of done vs test cases: what's the difference?
| Artifact | Applies to | Question it answers |
|---|---|---|
| Acceptance criteria | One specific story or feature | Does this feature behave exactly as specified? |
| Definition of done | Every story, set team-wide | Did we follow our quality process: tests, review, docs? |
| Test cases | The implementation | Do concrete inputs produce the expected outputs step by step? |
How is acceptance criteria used in practice?
Specs the PRD Agent writes
ProductOS's PRD Agent drafts specs section by section, giving downstream agents verifiable targets instead of vague intent. Criteria written at the spec stage become the standard the build is checked against.
QA Agent verification
The ProductOS QA Agent runs tests in real headless Chromium, along with axe accessibility audits and API checks. Testable criteria are what those automated checks assert, closing the loop between spec and verification.
Verifying in live preview
Every ProductOS project runs in an isolated cloud sandbox with a live preview URL. Founders can walk their own acceptance criteria against the running app before anything deploys.
Frequently asked questions
Who writes acceptance criteria?
Usually the product manager drafts them with the story, then refines them with engineers and QA, who are best at spotting missing edge cases. On AI-assisted teams this drafting step matters more, not less, since any criterion left ambiguous becomes the agent's assumption.
What is the Given/When/Then format?
It is a behavior-driven structure for criteria: Given a starting state, When the user acts, Then the expected result occurs. For example: given a logged-out user, when they open a shared link, then they see a read-only view. The format forces you to state context, action, and outcome explicitly.
How many acceptance criteria should a user story have?
Most well-scoped stories carry roughly three to seven criteria. Fewer than three often means the story is underspecified; many more than seven usually means it is really two stories and should be split. Treat the count as a smell test, not a rule.
Are acceptance criteria the same as requirements?
They overlap but sit at different altitudes. Requirements describe what the product must do overall; acceptance criteria pin one story's requirements down to verifiable checks. Think of criteria as requirements sharpened to the point where a tester, or an automated QA agent, can answer pass or fail.
Related terms
- User storyA user story is a short, plain-language description of a feature told from the user's perspective, typically written as "As a [user], I want [goal] so that [benefit]," keeping development focused on outcomes rather than outputs.
- Product requirements document (PRD)A product requirements document (PRD) is a structured specification that defines what a product or feature should do and why, covering the problem, target user, scope, user stories, and acceptance criteria that guide design and engineering.
- BacklogA backlog is the ordered list of features, bug fixes, improvements, and ideas a product team intends to build, ranked so that the items at the top represent the team's actual next commitments rather than a wish list.