What is Acceptance Criteria?
Acceptance criteria are the specific, testable conditions a piece of work must satisfy before it is considered done. Written before development starts, usually alongside a user story, they turn intent into a pass-or-fail check, so the team, testers and stakeholders share one unambiguous definition of complete.
Reviewed by Gensudo Team · 23 July 2026
In more depth
Each criterion describes an observable outcome, not an implementation: what the system does in a given circumstance, from the user's point of view. Common formats include simple checklists and the Given/When/Then structure ('Given an expired card, when the user submits payment, then a clear error names the problem and preserves the basket'). Good criteria cover the unhappy paths — errors, edge cases, permissions — because that is where undefined behaviour hides. They are also the natural boundary marker: anything not in the criteria is a new conversation, not an assumed inclusion.
Why it matters
The costliest bugs are often not coding errors but interpretation gaps — the developer built what they understood, and it was not what was meant. Acceptance criteria surface those gaps before build, when fixing a misunderstanding costs a sentence rather than a sprint. They also make review and testing objective: work is judged against agreed conditions, not against a reviewer's evolving expectations, which reduces both rework and friction.
A product example
For a password-reset story, the criteria specify: a reset email arrives within a defined time; the link expires after a set period and cannot be reused; an expired link shows a clear message with a way to request another; and a successful reset ends other active sessions. During testing, each line is checked and passed — including the reuse case the first implementation had missed.
Documents where this shows up
Product Requirements Document (PRD) for Product Managers · Product Launch Checklist for Product Managers