Acceptance Criteria

8 min read

Acceptance Criteria

Specific, testable conditions that define when a user story is complete — the contract between “what we asked for” and “what we built.”

What are acceptance criteria?

Acceptance criteria (AC) are the conditions that must be true for a user story to be considered done. They transform a vague wish (“make it work”) into something verifiable (“given X, when Y, then Z”). They are the bridge between the user story (what and why) and the technical-specification (how exactly).

Research shows that requirements-related issues cause nearly half of all software defects — and most trace back to unclear or missing acceptance criteria.1

In plain terms

Acceptance criteria are like the checklist a building inspector uses. The architect drew the plans (user story), the builders constructed the house (development), but nobody moves in until the inspector confirms: “the wiring passes code, the plumbing doesn’t leak, the fire exits work.” Without the checklist, “done” is just someone’s opinion.

At a glance

How do acceptance criteria work?

1. The Given-When-Then format

The most common structure for acceptance criteria, borrowed from Behaviour-Driven Development (BDD):2

Given [a starting condition]
When  [an action happens]
Then  [an expected result]

This format is powerful because every criterion becomes a testable scenario. For example:

GivenWhenThen
A citizen has selected “housing” as their problem areaThe system displays matching instrumentsAt least two instruments are shown, each with name, requirements, and timeline
A user has uploaded a profile photoThey click “save”The photo appears as their avatar within 2 seconds
The search field is emptyThe user clicks the search buttonAn inline message says “Please enter a search term”
A reader has three unread notificationsThey open the notification panelThe three notifications are listed newest-first with timestamps

Think of it like...

Given-When-Then is the structure of a science experiment. Given the lab conditions (controlled environment), when you add the chemical (action), then the solution turns blue (observable result). If it doesn’t turn blue, the experiment failed — no ambiguity.

2. Rule-based format

An alternative to Given-When-Then — a simple bullet list of conditions that must hold true:3

  • File uploads must be under 10 MB
  • Error messages appear within 3 seconds
  • Results are paginated at 20 items per page
  • Empty results show a “no matches found” message, not a blank page

Use whichever format your team prefers. Given-When-Then works well for interactive behaviour; rule-based works well for constraints and non-functional requirements.

3. What makes good acceptance criteria

QualityGoodBad
Specific”Response loads in under 3 seconds""It should be fast”
Testable”Error message says ‘File too large’""Handle errors gracefully”
IndependentTests one behaviourTests multiple features at once
User-focusedDescribes what the user sees/experiencesDescribes internal implementation

The acid test

For each criterion, ask: “Can I write a pass/fail test for this?” If the answer is no, the criterion is too vague.

4. How many criteria per story?

3-8 is the sweet spot.2 Fewer than 3 usually means the story is under-specified — you haven’t thought through edge cases. More than 8 usually means the story is too large and should be split into smaller stories.

Think of it like...

The items on a pilot’s pre-flight checklist. Too few items and you miss something critical. Too many and the checklist becomes impractical — nobody reads a 50-item list carefully. Aviation solves this by having separate checklists for each phase (taxi, takeoff, climb). Software solves it by splitting big stories into smaller ones.

Why do we use acceptance criteria?

Four reasons

1. They define “done” objectively. No more arguing about whether something is finished. Either the criteria pass or they don’t.3

2. They prevent rework. Requirements-related issues cause roughly half of software defects. Clear acceptance criteria catch misunderstandings before code is written, not after.1

3. They enable testing. Each criterion maps directly to a test case. A story with 5 acceptance criteria gives you 5 tests — no guesswork about what to test.2

4. They align the team. Developers, designers, and stakeholders agree on what success looks like before building starts. Surprises at review time drop dramatically.

When do we use acceptance criteria?

  • When writing user-stories — every story should have criteria from day one
  • During sprint planning — to refine stories and estimate effort (the criteria reveal the real complexity)
  • When working with AI — acceptance criteria become the AI’s success criteria: “build this, and it’s done when these conditions are met”
  • When testing — each criterion becomes one test case
  • When reviewing — the reviewer checks the feature against the criteria, not against personal opinion

Rule of thumb

If you can’t write a test for it, it’s not an acceptance criterion — it’s a wish.

How can I think about acceptance criteria?

The recipe's "done" test

A recipe doesn’t just list ingredients and steps. It tells you how to know it’s done: “bake until golden brown,” “the internal temperature reaches 75 C,” “the centre is no longer wobbling.” These are acceptance criteria for cooking.

  • The recipe = the user story (what you’re making and why)
  • The steps = the technical implementation (how you build it)
  • “Bake until golden brown” = an acceptance criterion (specific, observable, pass/fail)
  • “Make it taste good” = NOT an acceptance criterion (subjective, untestable)

Without the doneness tests, you’re guessing whether the cake is ready.

The driving test

The driving test has explicit pass/fail criteria: mirror check before pulling out, full stop at red lights, speed within limits, parallel park within the marked lines. The examiner doesn’t grade “vibes” — they check specific observable behaviours.

  • The driving test = the set of acceptance criteria
  • Each criterion = one observable behaviour (did they check mirrors? did they stop at the light?)
  • The examiner = the tester or reviewer
  • Pass/fail = objective, not negotiable

That’s exactly what acceptance criteria do for software: specific, observable, pass/fail.

Concepts to explore next

ConceptWhat it coversStatus
user-storiesThe format for capturing what a user needs and whycomplete
technical-specificationHow to turn stories and criteria into precise system behaviourcomplete
spec-driven-developmentWriting the spec before the code — criteria as the starting pointcomplete
scope-managementHow to decide what’s in and what’s out of a releasecomplete

Some of these cards may not exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

Check your understanding

Where this concept fits

Position in the knowledge graph 

graph TD
    PR[Product Requirements] --> PRD[PRD]
    PRD --> US[User Stories]
    PRD --> SM[Scope Management]
    US --> AC[Acceptance Criteria]
    AC -.->|informs| TS[Technical Specification]
    AC -.->|connects to| SDD[Spec-Driven Development]
    style AC fill:#4a9ede,color:#fff

Related concepts:

  • technical-specification — the spec says how exactly to build what the criteria define as done
  • spec-driven-development — a workflow where acceptance criteria are written before any code, driving the entire development process
  • scope-management — criteria help define scope boundaries: if it’s not in the criteria, it’s not in scope
  • iterative-development — criteria evolve across iterations as the team learns what users actually need

Sources

Further reading

Resources

Footnotes

  1. Kollabe. (2026). How to Write Acceptance Criteria. Kollabe. ↩ ↩2

  2. Nora. (2025). Acceptance Criteria for User Stories: A Complete Guide. Nora. ↩ ↩2 ↩3

  3. Atlassian. (2026). What is Acceptance Criteria?. Atlassian. ↩ ↩2

Graph View

Backlinks