Key takeaways
  • Acceptance criteria are the contract that turns "what we said" into "what we'll know we did".
  • Apply the five-second test; AC aren't a spec, a test plan or a wish list.
  • The forgotten AC (edge cases and non-functional needs) are where quality leaks.

Acceptance criteria are the contract. They turn "what we said we'd do" into "what we'll know we did" — and they're the only part of a user story that gets looked at twice. The PM writes them once. The engineer reads them three times. The reviewer reads them at acceptance. The auditor (in regulated work) reads them again two years later. If your AC don't survive that pass-by-pass scrutiny, the work that lands won't either.

This issue is about the rules that make AC survive. There aren't many. But the teams that hold to them ship cleaner work, and the teams that don't end up arguing about what "done" meant six weeks after release.

What an AC is.

An acceptance criterion is a single, verifiable statement of an outcome the system will support once the story ships. It has three properties, every time:

  • Objectively checkable. A reviewer can look at the system and decide true or false. No interpretation needed.
  • Stated as a positive outcome. What's now true, not what the work involved. "The user can do X", not "We built X".
  • Scoped to this story. The AC describes this story's contribution. Don't repeat criteria that belong to a related story.

You can write AC in two common formats. The one we use is the ✅ tick-list (see the User Story piece for a worked example). The other is the Given / When / Then form (Behaviour-Driven Development style), which gets more structured but more verbose. Either works. Consistency within a team matters more than which one you pick.

Diagram · Weak AC vs strong AC — the five-second test
Weak acceptance criteria versus strong acceptance criteria Four side-by-side comparisons showing how to rewrite a weak acceptance criterion into a strong one. Row 1: weak "The flow feels intuitive" becomes strong "A new user completes the booking flow without help text within 90 seconds". Row 2: weak "Performance is good" becomes strong "The dashboard renders to interactive in under 2 seconds at the 95th percentile on a 4G connection". Row 3: weak "Bugs are fixed" becomes strong "All open bugs in the linked issue list are closed and verified by the QA reviewer". Row 4: weak "Search works correctly" becomes strong "A query for an existing show returns that show as the top result; a query with a typo of up to one character returns the same top result". The pattern: replace subjective adjectives with measurable conditions, replace process language with state language, and scope AC tightly to this story. WEAK · subjective, not testable STRONG · objective, checkable UX "The flow feels intuitive." UX · MEASURED A new user completes the booking flow without help text within 90 seconds. PERFORMANCE "Performance is good." PERFORMANCE · MEASURED Dashboard renders to interactive in < 2s at p95 on a 4G connection. DEFECTS "Bugs are fixed." DEFECTS · SCOPED All open bugs in the linked issue list are closed and verified by the QA reviewer. FUNCTIONAL "Search works correctly." FUNCTIONAL · SPECIFIED A query for an existing show returns it as top result. A typo of up to one character returns the same top result. The pattern · subjective → measurable · process → state · vague → scoped
If you can't picture exactly what a reviewer would do to test the AC, it's weak. Replace subjective adjectives with measurable conditions, process language with state language, and vague scope with named lists. Five-second test: would two reviewers, independently, get the same true/false answer? If yes, it's an AC. If no, it's a wish.

The five-second test.

The fastest way to spot a weak AC is to imagine two reviewers, looking at the system independently, having to give a true/false answer. If they'd get the same answer, the AC is strong. If one would say "yes" and the other "well, it depends," it's weak — replace it.

Subjective adjectives are the most common giveaway. Intuitive, fast, simple, clean, smooth, robust, user-friendly. None of these survive the five-second test. Each one needs to be replaced with a measurable condition: a time, a percentile, a named threshold, a verifiable state.

If two reviewers wouldn't independently give the same true/false answer to your AC, it's not an AC — it's a wish.

What AC aren't.

  • Not a re-statement of the Requirements. Requirements describe decisions ("Treat X as the parent group"). AC describe the verifiable outcome after the decision is implemented ("Items previously in Y now appear under X"). Different jobs.
  • Not a test plan. A test plan is how QA will verify. AC are what they'll verify. Don't write your AC in Gherkin if your team isn't using BDD. You'll get the worst of both formats.
  • Not the place for error handling that lives elsewhere. If "the user sees a friendly error if the upload fails" is its own story, don't bury its AC inside the upload-happy-path story.
  • Not optional. A story without AC isn't a story — it's a feature request.

How many AC per story?

Five to eight is the sweet spot for most stories. If you're at twelve+, you probably have two stories disguised as one. Split. If you're at one or two, you probably haven't thought through error cases or edge behaviour, so push back on yourself. Each AC should be earning its place; if removing one wouldn't change what "done" means, it doesn't need to be there.

The AC that get forgotten.

The AC most teams skip (and the ones that bite hardest when missed) are the cross-cutting ones. Accessibility (WCAG AA contrast, keyboard reach, screen-reader labels). Audit and logging ("every action of type X is logged with actor, timestamp, payload"). Permissions and visibility ("only users with role Y can see this surface"). Mobile parity ("the same flow completes on a 375px viewport without horizontal scroll").

If your team's stories don't have AC like these on by default, your Quality Piece probably isn't strong enough yet. The Quality function's job is partly to keep cross-cutting AC live on every story — not retrofitted as bugs after release.

Where this lands.

Strong AC are downstream of a strong PO Piece and upstream of a strong Quality Piece. They make refinement faster, acceptance cleaner, and the release-confidence model real. If your AC are leaking, the Diagnostic will tell you whether it's a PO gap, a Quality gap, or a PM gap (PMs who skip AC have skipped the discovery work too).

Next issue: The Backlog — what healthy looks like. The three layers, the anti-patterns, and how often to groom.