Acceptance Criteria

Acceptance criteria answer "how do we know this is done?" before anyone starts building, instead of arguing about it afterward.

They're usually written as a short list of specific, checkable statements, often in Given/When/Then form:

Given a user is on the checkout page with an expired card, When they submit the payment, Then they see an error message and the order is not created.

Good acceptance criteria are specific enough to test directly and worded in terms of behaviour, not implementation.

Why they matter

Without them, "done" is subjective — a developer thinks it's done, a reviewer disagrees, and the disagreement surfaces late, after the work is finished. With them, everyone — product, engineering, QA — agreed on the bar before work started, and that same list becomes the test scenarios used to check it.

In practice

Acceptance criteria are a natural source for a plain-English test suite: each criterion, written in plain language, translates almost directly into a check Manta can run every release — turning "how do we know this is done" into "how do we know it's still done."