Acceptance Criteria

Acceptance criteria are the specific conditions a piece of work must satisfy to be considered complete. They accompany a requirement or user story, are agreed before work begins, and provide the objective basis on which the result is assessed. Their function is to convert a general description of intent into something that can be verified rather than debated.

Their absence produces a predictable and expensive pattern. Work is described in general terms, built according to one person's interpretation, and reviewed by someone with a different interpretation, at which point the disagreement surfaces as rework at the least convenient moment. Writing the criteria first moves that disagreement to the point where resolving it costs a conversation rather than a rebuild.

Two formats dominate. A simple checklist states each condition that must hold, which suits straightforward requirements and is quick to write. The given-when-then structure, drawn from behaviour-driven development, states a starting context, an action, and an expected outcome, which suits conditional behaviour and maps directly onto automated tests. Neither is inherently superior, and consistency within a team matters more than the choice.

The most valuable criteria are the ones covering what the narrative omits. The happy path is usually obvious and rarely disputed; the disputes concern validation rules, error states, empty and extreme data, permission boundaries, what happens when an external service fails, and how the behaviour differs across devices. Teams that write criteria only for the expected case discover the rest during testing, which is where the schedule usually goes.

Criteria describe outcomes rather than implementation, which preserves the team's ability to choose an approach. Stating that a user must receive confirmation within a defined period is a criterion; stating which queue technology should send it is a design decision that does not belong in an acceptance statement. Criteria that specify implementation constrain the people best placed to decide it and frequently encode a solution that turns out to be unnecessary.

Traceability between criteria and tests is what keeps the two from diverging over time. Where each criterion maps to a verification, whether automated or manual, the coverage is visible and a change to the requirement prompts a change to the test. Where they are maintained separately, the tests gradually come to describe what the system does rather than what it was required to do, which removes their ability to catch regression against intent.

Non-functional expectations belong in criteria when they matter, and are usually omitted. Performance thresholds, accessibility requirements, browser and device support, and security constraints are all conditions of acceptance, and leaving them implicit means they are addressed inconsistently or discovered in a later audit. Where a team has a shared definition of done covering these across all work, the individual criteria need only state deviations from it.

Writing them collaboratively is what produces the benefit rather than the document itself. Criteria drafted by one person and handed over transfer a specification; criteria discussed between the person who wants the capability, the person building it, and the person testing it surface the ambiguities while they are still cheap. The discussion frequently changes the requirement, which is the point.

Because the criteria define what will be tested, they connect requirement definition directly to quality assurance rather than treating them as sequential stages. In practice they are written within product development as part of refinement, with the usability and accessibility conditions informed by the standards established through UX audit work, so that what counts as acceptable reflects the experience the product is meant to deliver rather than only its functional behaviour.