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.¹

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 acceptance criteria fit into a user story's lifecycle (click to expand)

sequenceDiagram
    participant PO as Product Owner
    participant Dev as Developer
    participant AC as Acceptance Criteria

    PO->>PO: Writes User Story
    PO->>AC: Defines Acceptance Criteria
    Dev->>Dev: Builds Feature
    Dev->>AC: Checks against criteria
    alt All criteria pass
        AC-->>Dev: Story is Done
    else One or more fail
        AC-->>Dev: Fix and re-check
        Dev->>AC: Checks again
    end

Key: The Product Owner defines success conditions before development starts. The Developer builds the feature, then verifies it against those conditions. Nothing ships until every criterion passes.

---

How do acceptance criteria work?

1. The Given-When-Then format

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

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:

Given	When	Then
A citizen has selected “housing” as their problem area	The system displays matching instruments	At least two instruments are shown, each with name, requirements, and timeline
A user has uploaded a profile photo	They click “save”	The photo appears as their avatar within 2 seconds
The search field is empty	The user clicks the search button	An inline message says “Please enter a search term”
A reader has three unread notifications	They open the notification panel	The 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:³

• 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

Quality	Good	Bad
Specific	”Response loads in under 3 seconds"	"It should be fast”
Testable	”Error message says ‘File too large’"	"Handle errors gracefully”
Independent	Tests one behaviour	Tests multiple features at once
User-focused	Describes what the user sees/experiences	Describes 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.² 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.³

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

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.²

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

Concept	What it covers	Status
user-stories	The format for capturing what a user needs and why	complete
technical-specification	How to turn stories and criteria into precise system behaviour	complete
spec-driven-development	Writing the spec before the code — criteria as the starting point	complete
scope-management	How to decide what’s in and what’s out of a release	complete

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

Test yourself (click to expand)

1. Explain why “the system should be user-friendly” is not a valid acceptance criterion. What would you write instead?
2. Write three acceptance criteria in Given-When-Then format for this story: “As a reader, I want to search articles by keyword, so that I can find relevant content quickly.”
3. Distinguish between acceptance criteria and a technical specification. Where does one end and the other begin?
4. Interpret this scenario: a developer marks a story as “done” but one acceptance criterion fails the test. Is the story done? What should happen?
5. Connect acceptance criteria to iterative-development. How do criteria change across iterations of the same feature?

---

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

• What is Acceptance Criteria? (Atlassian) — Beginner-friendly overview with examples and best practices
• How to Write Acceptance Criteria (Kollabe) — Practical guide covering formats, common mistakes, and the cost of unclear requirements
• Acceptance Criteria for User Stories (Nora) — Complete guide with Given-When-Then and rule-based examples
• How to Write Acceptance Criteria Using Given-When-Then — Focused tutorial on the BDD format with code-level examples
• Acceptance Criteria: How to Define and Deliver (TaskFord) — Broader perspective on aligning teams through criteria

Footnotes

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

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

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