---
title: "What Are Acceptance Criteria? Examples and Format 2026 | ProductOS"
description: "Acceptance criteria are the specific, testable conditions a feature must satisfy before it counts as complete, giving engineers, testers, and AI agents a shared"
url: https://productos.dev/glossary/acceptance-criteria
---

# What is Acceptance criteria?

By [Heemang Parmar](https://productos.dev/blog/authors/heemang-parmar) · Updated July 2026 · [Editorial policy](https://productos.dev/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?

1. 1

**Start 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.
2. 2

**Make each one testable:** Write binary pass-or-fail conditions with numbers where they matter: "completes in under 10 seconds," not "feels fast."
3. 3

**Cover the edge cases:** Spell out empty states, errors, permissions, and repeat actions, since these gaps are where most post-launch bugs hide.
4. 4

**Agree 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](https://productos.dev/agents/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](https://productos.dev/agents/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.

See how Acceptance criteria works inside ProductOS, from research to shipped code.

[Try ProductOS free ](https://beta.productos.dev/)

## 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.

[AI PRD Generator](https://productos.dev/products/define)

## Related terms

- [User story A 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.](https://productos.dev/glossary/user-story)
- [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.](https://productos.dev/glossary/product-requirements-document)
- [Backlog A 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.](https://productos.dev/glossary/backlog)

[All glossary terms](https://productos.dev/glossary)