Acceptance Criteria

You are learning this because it is the step that turns a vague request into a testable definition of done. Without acceptance criteria, every feature you build will be judged by opinion, and every disagreement with your reviewer or AI agent will be a fight about taste. With them, you can look at a task and say, 'I am finished because these three conditions hold.' This concept unlocks: Test-Driven Development, where acceptance criteria become automated tests before any code is written; Requirements Traceability, where each criterion maps back to a requirement and forward to a test; and Spec-Driven Development as a whole, where written specifications, not vibes, drive the work. You will also need it for Task Cards — a criterion is what makes a task small and self-contained enough to hand to an agent or a teammate.

Think of a time someone asked you to 'make something nice' or 'improve the app a bit.' What did they mean? You had no way to know if you were done, because there was no definition of done. Acceptance criteria are the cure for that. They are a list of specific, measurable conditions that must be true for the work to count as finished. They are not a description of the work itself — they are the tests you will run against the work to prove it is done. If a condition says 'the login button is blue,' you can look at the button and say 'yes' or 'no.' If a condition says 'the user can log in,' you can click it and try. If a condition says 'it feels good,' you cannot test it at all — that is an opinion, not a criterion. Writing acceptance criteria before you start building forces you to think about what 'done' means, and it exposes all the hidden assumptions that live in a vague request. It also makes handoff possible: you can hand a task with clear criteria to anyone or any AI agent, and they can know when they are done without asking you.

A recipe. Suppose your friend asks you to 'make something for dinner.' You have no idea what to cook, how much to make, or when it is ready. Now suppose your friend gives you a recipe: 'Make a vegetable curry. The sauce should be thick enough to coat a spoon. It should serve four people. It should be ready in forty minutes.' Now you know exactly what to do and when it is done — the sauce thickens, the portion serves four, the timer rings. Acceptance criteria are the 'thick enough to coat a spoon' part. The recipe itself is the requirement — what to cook. The criteria are the checks you run against the finished dish to know you succeeded. Where does the analogy stop working? A recipe is a series of steps, while acceptance criteria are not steps — they are conditions on the final result. You don't check 'cook for forty minutes' as a criterion; you check 'the curry is done when the timer rings AND the sauce is thick' — the timer is a step, the thickness is a criterion. Also, a recipe can be subjective (what does 'thick enough' mean?) — a good acceptance criterion is so precise that two different people reading it would agree, without needing a taste test. 'Thick enough to coat a spoon' might still be argued over; 'the sauce leaves a thin film on a spoon that does not drip for five seconds' is unambiguous.

Acceptance criteria are a set of testable conditions, written before implementation begins, that define when a requirement is satisfied, so that 'done' is a verified fact rather than a personal opinion.

This concept builds directly on Engineering Intent Documents and Product Requirements Documents — you write an intent to capture the direction, then a PRD to state what the product must do, and then you write acceptance criteria to make each requirement in that PRD testable. Each criterion should map back to at least one requirement, and later, when you study Requirements Traceability, you will connect each criterion forward to a test in code. This concept also feeds into Spec Drift and Review Gates — criteria are what a review gate checks against, and they are what makes drift detectable. Of your neighbouring topics, the strongest link is to Test Planning, which turns acceptance criteria into actual automated tests.