What is acceptance criteria? Definition for product teams

Acceptance criteria is the checklist that decides whether a user story or work item is done: the conditions that must be true for the change to count as shipped.

The format earns its keep because "done" is otherwise a moving target. Without the criteria written down up front, engineering and product can disagree at review time about whether the work matches the intent, and the disagreement is hard to resolve because no one wrote the intent down.

The shape that works

Each criterion is a single concrete statement that is either true or false at review time. "When a logged-out user clicks Buy, they see the signup modal." "When the cart is empty, the checkout button is disabled." Vague statements ("it should feel responsive") fail the test, because there is no way to verify them.

A useful side-effect is that acceptance criteria double as test cases. The QA pass walks the list. A visual feedback session against a staging build can verify each criterion individually, and the resulting markdown document tells engineering (or an AI coding agent making the fix) exactly which criteria failed and what was seen instead.

Frequently asked questions

How is acceptance criteria different from definition of done?

Acceptance criteria is per-story: the specific behavior this change must produce. Definition of done is per-team: the universal bar everything must clear (tests pass, code reviewed, deployed).

Who writes acceptance criteria?

Usually the PM or whoever owns the story, in collaboration with engineering. The most useful version is written before the work starts, not after.