acceptance criteria

Also called: acceptance criterion

Checkable conditions agreed in advance that a specific deliverable must meet before someone accepts it. "Good lessons" is a wish; "every topic has a worked example and ten graded practice tasks" is a criterion.

Acceptance criteria are checkable conditions, agreed before the work starts, that one specific deliverable must meet before someone accepts it. "Good lessons" is a wish: the people doing the work can't aim at it, and nobody can turn it down without a fight. "A random sample of 20 tasks has no factual errors" is a criterion.

Three things make a criterion work. A named acceptor runs it: the expert who can judge the work or the person who will rely on it, not the person who built it. A method comes with it: a sample, a test purchase, a pilot with a few users. A check without a way to run it is still a wish. And a failure rule is agreed in advance: what happens when the sample finds an error, so nobody negotiates the bar under pressure.

Small checks are smoke tests, not proof. Three pilot users agreeing with an expert catches a broken tool; it doesn't prove the tool is accurate. Write that limit into the criterion, and name where the real evidence will come from later.

Agree criteria before the work: written after delivery, they describe whatever was delivered. When something fails close to a deadline, decide openly: fix it, cut it, or accept it with a written exception that the sponsor signs. What you don't do is quietly lower the bar. Acceptance criteria are specific to one deliverable; the definition of done is the checklist that applies to every piece of work.

Example

Acceptance criteria for three deliverables of Klasna's physics launch, agreed in late October 2026:

Deliverable	Criteria	How it's checked	Who accepts
Practice set	A random sample of 20 tasks has no factual errors; every task has an answer and an exam topic. If the sample finds an error, the author rechecks the whole set and a new sample is drawn	Vira solves the sample herself	Vira, academic lead
Diagnostic test	Places 3 pilot learners at the level Vira finds in a 20-minute talk; runs on a phone and a laptop; every result is saved	Pilot with 3 learners	Vira
Landing page	Shows the 8, 16 and 32-lesson packages with prices; books a physics lesson end to end; works on a phone	A test purchase on a phone	Someone who didn't build it

The diagnostic test criterion carries its limit in writing: three learners is a smoke check that catches a broken test before launch, and placement accuracy will show only in the February data.

That data also shows what acceptance criteria can't do. The test passed "runs on a phone", yet in February 35% of the learners who started it on a phone finished it, against 64.71% on a computer. The criterion checked that the test worked; whether it worked well enough for families is a question for the success criteria.

Common mistakes

Wishes instead of checks. "Engaging", "high quality" and "the CEO likes it" can't fail on a given day.
The builder accepts their own work. The acceptor is the expert or the user, not the author.
Criteria written after delivery. They end up describing whatever was delivered.
No rule for a failed check. Agree up front what happens when the sample finds an error.
A smoke check read as proof. Three pilot users catch a broken tool; they don't prove it's accurate.

Learn it in the course

Acceptance criteria: what "done" means · "Good lessons" is a wish nobody can accept. Write checks a named person can run, agree them before the work starts, and say what happens when one fails.
Risk responses, the pre-mortem and built-in quality · Choose a response for each risk (avoid, transfer, reduce, accept or escalate), use opportunities, find hidden risks with a pre-mortem, and check quality while the work is done, not at the end.
Build, buy or hire: contracts by how clear the scope is · Decide per piece of work, pick a fixed price or time and materials by how clear the scope is, write a short request for proposals and pay for accepted work.
Must, should, could: cut scope, not the date · When the list is longer than the time, sort every deliverable with one test, agree in advance what is dropped first, and keep the fixed date.
Acceptance and handover to operations · Run the acceptance checks against the real thing, write known problems down with owners, hand each part to an everyday owner and keep a runbook for outages and alerts.