Acceptance criteria are the specific, checkable conditions a piece of work must satisfy to be accepted. They answer one question — how will we know this is done — and they must be answerable by observation rather than by opinion.
The test for a good criterion
Could a person who did not build it verify this without asking the author what it means? If not, it is a description, not a criterion.
- Weak: "The search should be fast."
- Better: "Search results render within 500ms at the 95th percentile for a catalogue of 100,000 items."
- Weak: "Handle errors gracefully."
- Better: "If the search service is unavailable, show the cached previous results with a stale-data notice; do not show an empty state."
Given / When / Then
The Given-When-Then structure exists to force the parts people skip — the precondition and the observable outcome:
Given a customer with an active subscription
And the subscription renews in fewer than 7 days
When they request cancellation
Then the subscription is marked cancel_at_period_end
And access continues until the period ends
And a confirmation email is sent within 5 minutes
Given a customer with no active subscription
When they request cancellation
Then they see a clear message that there is nothing to cancel
And no email is sentThe second scenario is the one teams omit and the one that produces the production bug.
Cover the unhappy paths or they will be invented
Criteria that only describe success leave every failure case to whoever implements it — and when implementation is machine-assisted, the failure case gets invented plausibly and silently. Roughly half your criteria should describe what happens when things go wrong, are missing, or arrive twice.
What they are not
- Not test cases. Criteria are what must be true; tests are how you verify it. One criterion often needs several tests.
- Not implementation. "Uses a database transaction" is a design choice; "either both records are created or neither is" is the criterion.
- Not a task list. "Update the API, update the UI, write docs" is a plan, not a definition of done.
Where they come from
The most reliable source is the conversation between whoever wants the change and whoever will build it — written down during that conversation, not reconstructed afterwards. Criteria written alone by either side tend to encode one party's assumptions, which is precisely the failure they exist to prevent.
Frequently Asked Questions
How many criteria should a story have?
Enough to remove ambiguity, typically three to seven. Twenty usually means the story is too large; one usually means the thinking has not happened yet.
Do criteria replace a PRD?
No. A PRD explains why and for whom; criteria define done for a specific piece of work. Small changes may need only criteria.
Who signs off?
Whoever requested the work, against the criteria as written. That is the point of writing them beforehand — acceptance becomes a check rather than a negotiation.
References
- Documenting Architecture Decisions — Michael Nygard / Cognitect
- The Agentic Engineering Trends Report 2026 — SaaSRise
About Jishu Labs
Jishu Labs is a software development company founded in 2016. We build custom software, AI/ML systems, and full-stack web and mobile applications for clients, and we make eight AI tools for software teams.