Acceptance criteria

Also called: conditions of satisfaction

Acceptance criteria are the observable outcomes a piece of work must produce before the person who asked for it will accept it.

Acceptance criteria describe what must be true for a story or feature to be accepted. Good criteria state outcomes a business owner can observe: the booking is confirmed, the invoice matches the order, the user is told why the upload failed. Poor criteria describe implementation, such as which endpoint a button calls.

They matter because every later conversation leans on them. Refinement uses them to size the work, testing uses them as the expected result, and UAT uses them to decide. When they are vague, each of those conversations turns into a negotiation about what was meant.

Before work starts I ask Product one question about the criteria: would you ship if only these pass? Hesitation means something is missing, and it is far cheaper to find at that point than in release week.

Notes on this

More on this subject: Product validation and acceptance criteria. Written by Marius Ene, senior QA consultant. See how I work with teams or browse all terms.