Acceptance criteria: what "done" means

Acceptance criteria are checkable conditions that one deliverable must meet, agreed before the work starts, with a named person who runs the check. They turn “done” from an opinion into a decision someone can make on a given day.

“Good lessons” is the deliverable nobody can accept. It's a wish: the freelance authors can't aim at it, and nobody can say no to it without a fight, because everyone means something different by “good”. Compare: “every exam topic of mechanics has a lesson plan, and Vira's review finds no factual errors.” Authors know what to produce; Vira knows what to check; a unit either passes or goes back.

Test any candidate line by asking could it fail? “Engaging and modern”, “the authors did their best” and “Leo likes how it reads” can't fail on any particular day, so they can't accept anything either.

Every set of acceptance criteria comes with one named person who runs the check, and it shouldn't be the author or the builder. The author checks the work against what they meant; the acceptor checks it against what the project needs.

Who fits? The person who will rely on the deliverable, or the expert who can judge it. For the curriculum and the practice sets, that's Vira: she knows exam physics and her tutors will teach from the material. For the landing page, the project lead is a fair acceptor: they didn't build it and can walk the families' path, checking it with a test purchase on a phone. For tutor onboarding, Roman's deliverable, the acceptor is someone other than Roman.

Name the acceptor when the criteria are written, not in the week before launch. An acceptor chosen at the last minute has nothing agreed to check against, and “it's live, so it's accepted” means nobody checked at all.

Experts usually describe quality in words: Vira's good practice set is “correct, at exam level and with answers”. Each word becomes a criterion once you ask how you'd check it on a real day.

“Correct” across three hundred tasks can't mean solving them all. It can mean a sample with a pass mark: Vira solves a random sample of 20 tasks and finds no factual errors. “With answers” becomes a field-by-field check: every task has an answer and an exam topic. And because a check can fail, agree the failure rule now: if the sample finds an error, that's a sign of more, so the set goes back, the author rechecks all of it, and Vira takes a new sample.

What stays out are hopes such as “high quality” or “learners will enjoy the tasks”. They may be true, but nobody can say on the day whether they're met, so they can't decide whether a set is accepted.

Turning a quality word into an acceptance criterion follows five steps, each resting on the one before.

1. Take the vague word: the practice set must be “correct”.
2. Ask what you'd see if it were true: tasks without factual errors.
3. Pick a method to check it: Vira solves a random sample, because nobody can solve three hundred tasks.
4. Set the pass mark: a sample of 20 tasks, no factual errors.
5. Agree what happens if it fails: the author rechecks the whole set and Vira takes a new sample.

The order isn't arbitrary. Without step 2 you'd pick a method that measures the wrong thing (for example, counting tasks). Without step 3 a pass mark has nothing to apply to. And the failure rule only makes sense once there's a check that can fail. The same five steps work for “accurate” on Danylo's test or “trustworthy” on the landing page.

Some deliverables can't be fully proven before launch, so their criteria use a small check and say honestly what it can and can't show.

Danylo's “works and is accurate” becomes: the test places three pilot learners at the same level Vira finds on her own after a twenty-minute talk, it runs on a phone and a laptop, and every result is saved. That's a smoke check: it catches a broken test before launch, such as a scoring bug that puts everyone at the top level.

It does not prove the test is accurate. Three agreements could happen by luck; whether placement is right shows only with more learners, in the February data. Write that limit into the criterion (“smoke check only; placement accuracy reviewed on February data”), so nobody later quotes three pilot learners as proof, and so someone actually looks at the February data.

Two kinds of “done” work at different levels, and a plan needs both.

A definition of done is one checklist for all work a team ships. Danylo's team has one: every release has code reviewed by a second developer and is tested. It doesn't change from piece to piece.

Acceptance criteria belong to one deliverable: what this landing page must do for families. It shows the 8, 16 and 32-lesson packages with prices, books a physics lesson end to end, and works on a phone, checked by a test purchase on a phone.

A line like “the landing page should feel trustworthy” is neither: it's a wish until it becomes a check. And when a deliverable fails a criterion close to launch and the sponsor accepts it anyway with a known gap, that's a written exception, signed by Leo, not a silent pass. Keeping the four apart shows exactly which promise a piece of work has kept.

Acceptance criteria work only if they're agreed before the work starts, by the owner, the acceptor and, where it matters, the sponsor.

Two reasons, both practical. First, criteria are a target: the freelance authors can aim at “a sample of 20 tasks with no factual errors” only if they know it while writing. Second, criteria written after delivery tend to describe whatever was delivered: once a set exists, it's very tempting to define “correct” so that it passes.

Disagreement is welcome, early. If the authors think a sample of 20 is too strict, let them argue now, and settle it: maybe 20 tasks with one typo allowed but no factual errors. Agreed in October, criteria are a shared target. In January, three weeks before launch, the same discussion is a fight about whether someone gets paid, with everyone tired and the date fixed.

Criteria are tested on bad days. Three days before launch, Vira's sample of 20 tasks from practice set 2 finds two factual errors, and everyone wants to just fix those two.

Two errors in a random sample are a sign of more in the tasks nobody sampled, so fixing them doesn't meet the criterion. Follow the failure rule agreed in October: the set goes back for a full recheck and a new sample. If it can't pass before launch, there are only three honest options: fix it in time, cut it from the launch, or accept it with a written exception Leo signs, knowing the gap.

What you never do is quietly lower the bar (“two in 20 is fine this time”) or accept silently. Either one makes every other criterion meaningless.

How it fits together: checkable criteria per deliverable, a named acceptor, agreed up front, with an honest response to failure. Next lesson: the list is longer than the time, so you sort it into must, should and could.