Acceptance criteria: how to write them

Acceptance criteria are a story's pass/fail test, written before work starts — the formats that work, worked examples, and how they differ from the definition of done.

Acceptance criteria are the conditions a story must meet to be accepted — a pass/fail test, written before anyone starts coding. No partial credit: each one is met or it isn’t. They describe what the result must do, not how to build it. And they are a test, not a second description of the feature. If you can satisfy them with code that doesn’t solve the problem, they aren’t acceptance criteria — they’re requirements in disguise.

Every story carries an implicit question: how will we know it’s finished? Acceptance criteria answer it out loud, before the work starts. 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 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 table of 10,000 rows” is, because anyone can test it and nobody has to read the code to do so.

They’re 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 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 backlog 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 effort hides.
  • 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.

Splitting by acceptance criteria

If a story has more than five acceptance criteria, the criteria are usually the split. The list is a backlog wearing a checklist hat.

Acceptance criteria exist to describe a story. They aren’t supposed to be the story. When the list gets long — six, eight, ten bullets — the team has often done the splitting work without noticing. Each criterion is a thin slice the team could ship, demo, and walk away from. Treating the whole list as a single commitment forces the team to take on all of it at once, which is the worst combination of size and risk you can hand someone in a sprint.

To split, take each criterion and ask the question you’d ask of any user story: would the team ship this on its own? Would the user benefit from it on its own? Could it be demoed? The bullets that survive that question are stories. The bullets that fail it usually belong to one of the survivors — they’re scope on a story you’ve already separated, not standalone work.

Where this fails is on tightly coupled criteria — “the form validates input and saves to the database and shows a confirmation.” Those three look splittable, but the user gets nothing if only one ships. That’s not splittable by criterion; it’s a single small story, and the bullets are just the team being thorough.

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.

Story points vs acceptance criteria

Acceptance criteria describe the outcome — what has to be true for the story to count as shipped. Story points describe the path — how big the work is between “we don’t have this yet” and “the criteria are satisfied.” Two different axes. Conflating them produces sized criteria, which is meaningless, or point estimates with no criteria behind them, which is wishful.

Does adding a criterion change the estimate? Sometimes. A criterion that surfaces hidden work — “must be accessible to screen readers” — usually does, because it names effort that was implicit. A criterion that just clarifies an existing assumption — “must work on Chrome and Safari” when those were always the supported browsers — shouldn’t. The order matters: criteria first, then points. Estimating before the criteria are clear is estimating before refinement, and it’s the most common cause of wide-spread votes.

Write the test before the work. If a criterion can’t fail, it isn’t one — and if you have more than five, you probably have more than one story.

Frequently asked 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 is 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 that depends on state, or a plain checklist for a set of independent requirements. Keep them testable, keep them about outcomes, and stop at around five — more than that and you are looking at several stories.

What is the difference between acceptance criteria and requirements?

Requirements say what to build; acceptance criteria say how you will know it is right. A requirement can be satisfied by code that misses the point. An acceptance criterion is a test — if it passes, that part of the story is done; if you can pass it without solving the user’s problem, it is a requirement in disguise.

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 are written with the team during refinement. The product owner 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.