Acceptance criteria
The story's pass/fail test, written before the work starts — not a second description of the feature.
Acceptance criteria are a test, not a description. If you can satisfy them with code that doesn't solve the problem, they're requirements in a costume.
Every story carries an implicit question: how will we know it's finished? Acceptance criteria answer it out loud, before anyone writes code. They're the conditions the result must meet to be accepted — pass or fail, no partial credit, no "well, mostly." Get them right and estimation gets easier, the demo writes itself, and "done" stops being a negotiation. Get them vague and you've shipped a feature nobody agreed on.
What acceptance criteria are — and what they're not
A good acceptance criterion is something you could hand to a tester who has never sat in your refinement meeting, and they'd know exactly what to check. It describes an outcome the user can observe, not the implementation that produces it. "Use a Redis cache" is not an acceptance criterion — it's a solution. "Results load in under a second for a 10,000-row table" is, because anyone can test it and nobody has to read the code to do so.
They are also not a wishlist. Each criterion has to be falsifiable. If a line can't be checked — "the page is intuitive," "performance is good" — it isn't a criterion, it's a hope. Cut it or make it measurable.
The two formats that work
Use Given/When/Then for behaviour that depends on state, and a plain checklist for a set of independent requirements. Most teams reach for Gherkin-style Given/When/Then for everything; resist that. A checklist is faster to read and harder to pad when the story is just "these five things must be true."
Given / When / Then
Given a starting state, When the user does something, Then the system responds a specific way. The format earns its keep by forcing you to name all three — the precondition, the trigger, and the observable result — which is exactly what a hand-wavy criterion leaves out.
Acceptance criteria examples
A login story, written as Given/When/Then:
- Given a registered user on the sign-in page, When they enter a correct email and password, Then they land on their dashboard.
- Given a registered user, When they enter a wrong password three times, Then the account locks for 15 minutes and they see how long is left.
- Given the sign-in page, When the email field is empty, Then the submit button is disabled.
A "filter the results table" story, written as a checklist:
- The filter applies on selection — no separate "apply" button.
- Two filters combine with AND, not OR.
- Clearing all filters restores the full, unsorted list.
- An empty result set shows the "no matches" state, not a blank table.
Notice what both leave out: the database, the framework, the component names. They say what the user gets, not how you'll deliver it — and each line is a thing a tester can pass or fail without asking you a question.
How to write acceptance criteria
- Write them during refinement, with the team — not alone, afterwards.
- One observable outcome per line. If a line has an "and" doing real work, it's two criteria.
- Name the unhappy path. The empty state, the timeout, the wrong input — that's where the points hide.
- Keep them about behaviour, not design. The mockup covers the layout; the criteria cover what has to be true.
- Stop at around five.
How many acceptance criteria is too many?
Roughly five. Not because there's a rule, but because a story that needs ten distinct, testable conditions is carrying ten distinct slices of value — which means it's several stories pretending to be one. When the list runs long, the acceptance criteria are the split: treat the list as a backlog and cut along it. A story you can't size usually isn't an estimation problem; it's an unwritten-criteria problem.
Acceptance criteria vs requirements
A requirement says what to build. An acceptance criterion says how you'll know you built the right thing. "Users can reset their password" is a requirement — and you can satisfy it with a flow so broken nobody completes it. "A user who requests a reset receives an email within two minutes whose link expires after one hour" is an acceptance criterion, because it's a test the broken flow fails. Requirements scope the work; criteria gate it.
Acceptance criteria vs the definition of done
These get conflated constantly, and the distinction is simple: acceptance criteria are per story; the definition of done is global. The criteria above describe what the login story specifically must do. The definition of done — tested, code-reviewed, documented, deployed to staging — applies to every story the team ships. A story can pass its acceptance criteria and still not be done, because "works as specified" and "ready to release" are different bars. You need both.
Write the test before the work. If a criterion can't fail, it isn't one — and if you have more than five, you have more than one story.
Common questions
What are acceptance criteria?
Acceptance criteria are the conditions a story must satisfy to be accepted — a pass/fail test written before the work starts. They describe what the result must do, not how to build it, and there's no partial credit: each one is met or it isn't.
How do you write acceptance criteria?
Write each one as something you could hand to a tester who has never seen the story. Use Given/When/Then for behaviour with conditions, or a plain checklist for a list of independent requirements. Keep them testable, keep them about outcomes, and stop at around five — more than that and you're looking at several stories.
What is the Given/When/Then format?
Given a starting state, When the user does something, Then the system responds a specific way. It forces you to name the precondition, the trigger, and the observable result — the three things a vague acceptance criterion leaves out.
What is the difference between acceptance criteria and requirements?
Requirements say what to build; acceptance criteria say how you'll know it's right. A requirement can be satisfied by code that misses the point. An acceptance criterion is a test — if it passes, the story is done; if you can pass it without solving the user's problem, it's a requirement wearing a costume.
What is the difference between acceptance criteria and the definition of done?
Acceptance criteria are per-story — they describe what this particular story must do. The definition of done is one global checklist that applies to every story (tested, reviewed, documented, deployed). A story can meet its acceptance criteria and still not be done if it skips the team-wide gate.
Who writes acceptance criteria?
The product owner owns them, but they're written with the team during refinement. The PO frames the outcome; the engineers and testers surface the edge cases. Acceptance criteria written alone, after the fact, are the ones that miss the case that breaks in production.
Adjacent: definition of done for the team-wide gate; splitting by acceptance criteria for when the list runs long; definition of ready for the checklist that gates a story into the sprint in the first place.