Testable Acceptance Criteria

Overview

Acceptance criteria define what "done" looks like for a user story. They are the contract between the person who requested the work and the team building it — written before development starts, agreed by both parties, and testable by someone who did not write the code. When acceptance criteria are absent or vague, every story ends with a negotiation about whether it is finished.

For writing the user stories that these criteria attach to, see Writing Effective User Stories. For preventing ambiguity before the sprint begins, see Reducing Ambiguity Before Sprint Start.

Why It Matters

Acceptance criteria are the only shared definition of "done" at the story level. Without them, "done" means something different to the developer, the tester, and the product manager. The difference surfaces in review — after the work is complete.

Well-written criteria are a test plan. A QA engineer reading good acceptance criteria should be able to write their test cases directly from them. Criteria that cannot be translated into test cases are not testable — and untestable criteria cannot be verified.

Criteria reduce scope creep during development. When a developer knows exactly what the story requires, they can push back on requests to add behaviour that is not in the criteria. Without criteria, every "while you're in there" addition looks legitimate.

Criteria expose missing edge cases before code is written. Writing Given-When-Then for a story almost always surfaces cases the author had not considered: "What happens if the user is logged out?" "What if the value is zero?" "What if two users edit the same record?" Finding these before a sprint starts is dramatically cheaper than finding them during testing.

The criteria writing process improves the story itself. Teams that write criteria collaboratively (product + engineering + QA) consistently discover that the story needs to be scoped, split, or clarified before it is ready to plan.

Standards & Best Practices

The Given-When-Then format

The standard format for individual acceptance criteria is:

Given [a specific starting context or precondition],
When [a specific action or event occurs],
Then [a specific, observable outcome results].

Each clause has a job:

• Given — establishes the state of the system or the user before the action. Vague preconditions produce inconsistent test results.
• When — describes the specific trigger. One action per criterion. If the trigger involves multiple steps, break it into multiple criteria.
• Then — describes an observable outcome that can be verified without interpretation. "The user sees a success message" is testable. "The user has a good experience" is not.

One scenario per criterion

Each acceptance criterion should cover a single scenario. Compound criteria — "Given X, when Y, then Z and also A and B and C" — hide multiple requirements in one statement. If a criterion has multiple "then" clauses, split it.

Cover the full scenario space

For most features, acceptance criteria should address:

• Happy path — the expected behaviour when everything works
• Error states — what happens when input is invalid, a service is unavailable, or the operation fails
• Boundary conditions — behaviour at the edges (empty state, maximum values, first-time users)
• Permission variations — different behaviour for different user roles or states
• Concurrent or repeat actions — what happens if the user submits twice, navigates away mid-flow, or performs the action from two devices

Not every story requires all of these. The exercise of asking the questions is what surfaces gaps.

Acceptance criteria vs Definition of Done

These are different things with different scopes:

Both apply to a story before it is truly done. Acceptance criteria cover what the feature does; definition of done covers how it was built.

When to write criteria

Acceptance criteria should be written and agreed before a story enters a sprint. The latest acceptable moment is the refinement session where the story is estimated. Criteria written during the sprint, or discovered during review, are a process failure.

The author of the criteria should be the product manager, in collaboration with the engineering lead and a QA representative (if available). Criteria written entirely by one person consistently miss perspectives the others would have contributed.

How to Implement

Writing session checklist

When writing acceptance criteria for a story:

1. Write the happy path first — what should happen when everything goes correctly?
2. Ask: "What could go wrong?" — map error states and system failures
3. Ask: "Who else might use this?" — identify permission variations or role-based behaviour
4. Ask: "What happens at the edges?" — empty states, maximum inputs, first-time users
5. Review each criterion: can it be verified by a person who did not build the feature?
6. Remove any criterion that cannot be stated as Given-When-Then
7. Get agreement from engineering that the criteria are buildable as written

Criteria quality checklist

Before a story with acceptance criteria enters a sprint:

• Every criterion is in Given-When-Then format (or equivalent explicit structure)
• Every "then" clause is observable and unambiguous
• Happy path is covered
• At least one error or failure state is covered
• Edge cases relevant to this story are covered
• No criterion contains subjective language ("user-friendly," "fast," "easy")
• Engineering has confirmed the criteria are buildable
• QA has confirmed the criteria are testable

Converting vague criteria

Tools & Templates

Acceptance criteria block (attach to each story)

### Acceptance Criteria

**Happy path**

- Given [context], when [action], then [outcome]

**Error state**

- Given [context], when [action fails or input is invalid], then [specific error behaviour]

**Edge cases**

- Given [boundary condition], when [action], then [outcome]

**Permission variation** (if applicable)

- Given [different user role or state], when [action], then [different outcome]

### Out of Scope

- [Scenarios explicitly not covered by this story]

Criteria review checklist (for refinement sessions)

For each criterion, ask:
[ ] Is the precondition (Given) specific enough to reproduce?
[ ] Is there exactly one trigger (When)?
[ ] Is the outcome (Then) verifiable without judgment?
[ ] Would two people reading this independently arrive at the same test?
[ ] Is this covered by the story, or does it belong in a separate story?

Common Pitfalls

Criteria written after the sprint starts. Acceptance criteria written mid-sprint are written to justify what was built, not to define what was needed. At that point they cannot prevent rework — they can only describe it.

Subjective outcomes. "The interface should be intuitive" is not a criterion — it is a hope. If the outcome requires interpretation to evaluate, it is not testable. Replace subjective language with specific, observable behaviour.

Only covering the happy path. A story with one acceptance criterion — the expected flow — is undertested. Most bugs live in error states, edge cases, and permission variations. If these cases matter (and they almost always do), they belong in the criteria.

Acceptance criteria as a specification. Fifteen acceptance criteria for a single story is a sign that the story is too large, not that the criteria are thorough. Stories with many criteria should be split. Each story should require 3–7 criteria to describe adequately.

Criteria that duplicate the story description. "Given a user who wants to filter by price, when they filter, then filtering works" adds nothing to the story. Criteria should describe specific, non-obvious outcomes — not restate the story title.

Skipping the engineering review. Product managers who write criteria without checking them with engineering often write criteria that contain implicit technical assumptions. "When the user saves, then the data is persisted instantly" may be incompatible with the architecture. Engineering review before sprint planning prevents these surprises.