Acceptance criteria template: Given/When/Then examples

Published 18 October 2026 · updated 22 October 2026

Acceptance criteria are the conditions a piece of work has to meet for the person who asked for it to accept it. They are agreed before the work starts, written so that anyone can check them, and checked when it ends. Below are two templates to copy — Given/When/Then and a checklist — worked examples, and the part most templates skip: what happens to the criteria when the requirement changes.

If you can’t tell if it meets the AC then you have badly written AC.

— r/ProductOwner, February 2025

Acceptance criteria format: Given/When/Then or a checklist

There are two formats, and most stories need both:

Aspect	Scenario: Given/When/Then	Rule: a checklist
Use it for	Behaviour that depends on a starting state and an action	Constraints that hold whatever happens: limits, formats, permissions
Example	Given four failed sign-ins, when the fifth fails, then the account is locked	Dates show as DD/MM/YYYY
Becomes	An automated test, almost line for line — Gherkin tools such as Cucumber read it	A check in review or testing

Given is the starting state, When is one action, Then is the result anyone can see. And adds a line to any of the three.

Teams that write their requirements in EARS write the criteria the same way, one sentence per rule: “When the fifth sign-in in a row fails, the system shall lock the account.”

Acceptance criteria template: Given/When/Then

Copy it into Jira, Linear, a document or a feature file. Everything in square brackets is yours to fill in.

STORY
As a [type of user]
I want [what they want to do]
So that [why it matters to them]

ACCEPTANCE CRITERIA

Scenario 1: [the normal case, in a few
            words]
  Given [the starting state]
  And   [anything else that must be true]
  When  [the user or the system does one
        thing]
  Then  [what anyone can see happen]
  And   [any other visible result]

Scenario 2: [an error or a refusal]
  Given [   ]
  When  [   ]
  Then  [   ]

Scenario 3: [an edge case: empty, at the
            limit, twice]
  Given [   ]
  When  [   ]
  Then  [   ]

MUST NOT CHANGE
- [existing behaviour this story has to
  leave alone]

OUT OF SCOPE
- [what this story does not do, that
  someone might assume]

AGREED
Requirement:  [id], version [x.y]
Agreed by:    [name, role]
Date:         [   ]

Acceptance criteria template: checklist

STORY: [title]

The story is accepted when:
[ ] [a rule anyone can check, e.g. "Only
    admins see the Export button"]
[ ] [a limit, e.g. "Exports up to 10,000
    rows"]
[ ] [a format, e.g. "Dates show as
    DD/MM/YYYY"]
[ ] [a message, e.g. "An empty result says
    'No orders'"]
[ ] [what must not change, e.g. "The JSON
    API response is unchanged"]

Out of scope:  [   ]
Agreed by:     [name, role], [date]
Requirement:   [id], version [x.y]

Acceptance criteria examples (Given/When/Then)

A sign-in lockout:

Story: As a customer, I want my account
locked after repeated wrong passwords, so
that nobody can guess it.

Scenario: Locked after five failed
          attempts
  Given a customer with an active account
  And   four failed sign-ins in the last
        15 minutes
  When  they enter a wrong password again
  Then  the account is locked for
        15 minutes
  And   they see "Too many attempts. Try
        again at [time]."
  And   an email tells them the account
        was locked

Scenario: The right password resets the
          count
  Given a customer with three failed
        sign-ins
  When  they sign in with the right
        password
  Then  they are signed in
  And   the failed sign-in count is back
        to zero

Exporting a filtered list, with rules beside the scenarios:

Story: As an account manager, I want to
export the orders I can see, so that I can
report on them in a spreadsheet.

Scenario: Export what is on screen
  Given the orders list filtered to
        "Shipped, last 30 days"
  When  the account manager selects Export
  Then  a CSV downloads with exactly the
        rows on screen
  And   its columns are the visible
        columns, in order

Scenario: Nothing to export
  Given a filter that matches no orders
  When  the account manager opens the list
  Then  the list says "No orders match
        these filters"
  And   the Export button is disabled

Rules
- Only orders the user is allowed to see
  are exported.
- The existing JSON API response does not
  change.

An API user story:

Story: As a partner calling our API, I
want a clear signal when I send too many
requests, so that my client can wait and
retry.

Scenario: Over the limit
  Given a partner key limited to 100
        requests a minute
  And   100 requests made in the current
        minute
  When  the partner sends another request
  Then  the response status is 429
  And   the Retry-After header gives the
        seconds to wait
  And   the request is not processed

Scenario: Under the limit
  Given 99 requests made in the current
        minute
  When  the partner sends another request
  Then  the request is processed as normal

How to write acceptance criteria for user stories

The story itself — format, examples, INVEST and splitting — is on the user story template page.

Write them before the work starts, with the people who will build and test it. Criteria written after the work is done turn into a negotiation.
Describe what anyone can see, not how it is built. “The account is locked”, not “set the locked flag in the users table”.
One scenario, one behaviour. If a Then needs “and also”, it is probably two scenarios.
Cover the unhappy paths: errors, refusals, empty states, limits, doing it twice.
Use numbers, not adjectives: “within 2 seconds”, not “fast”.
Say what must not change. On an existing system, that is where the surprises are.
Write what is out of scope next to the criteria.
Have them agreed by whoever will accept the work — the client or the product owner, not only the team.

Detail has a cost, though. Criteria that describe the screen pixel by pixel take the design away from the team:

I used to make tickets with very detailed acceptance criteria (this button there; this color; these edge cases). Now, they get a user problem and a scope for when that problem is solved.

— r/ProductOwner, February 2026

Good vs bad acceptance criteria

Bad	What is wrong	Better
The page loads fast	Nothing to measure	The order list shows within 2 seconds with 1,000 orders
Error messages are user-friendly	An opinion	A wrong card number shows “Check the card number” under the field
Store sessions in Redis	How, not what	A signed-in user stays signed in after a server restart
Export works	No starting state, no result	Given a filtered list, when the user exports, then the CSV has exactly the rows on screen
Handles all edge cases	Cannot be checked	An empty list, 10,000 rows and a second click while exporting are each a scenario

Acceptance criteria vs definition of done

Aspect	Acceptance criteria	Definition of done
Applies to	One story or requirement	Every piece of work
Says	What this piece of work must do	The quality bar all work must meet
Example	“Locked after five failed sign-ins”	“Code reviewed, tests pass, deployed to staging”
Written by	The product owner or analyst, with the team, agreed with whoever accepts it	The team, or the whole organisation
Changes	With the requirement	Rarely

The Scrum Guide defines the definition of done — “a formal description of the state of the Increment when it meets the quality measures required for the product” — and does not mention acceptance criteria at all. They come from practice, not from Scrum. Examples and a checklist: definition of done.

Acceptance criteria vs test cases: the criteria say what must be true; a test case says how to check it, step by step, with data. One criterion usually needs several test cases — see the test case template.

Acceptance criteria vs requirements

Requirements are what you’re supposed to do. Acceptance Criteria are the agreed upon measures to prove you’ve done them.

— Stack Exchange, 2013

The requirement is the rule; the criteria are the cases that show the rule holds, including the ones at its edges. The payment reminder from the customer portal:

FR-016  Payment reminder
One reminder, seven days after the due
date, for every invoice not paid in
full.

Acceptance criteria
1. An invoice due on 1 March and unpaid
   on 8 March: one reminder that day.
2. The same invoice on 9 March: no
   second reminder.
3. An invoice paid in full on 5 March:
   no reminder.
4. An invoice partly paid by 8 March:
   one reminder.

A requirement without criteria can only be accepted by opinion. Criteria without a requirement are a list of tests with no rule behind them: when one changes, nobody knows which rule changed. They belong together, and they change together — criterion 4 was added when the part payments change (CR-10) changed FR-016, in version 1.4.

Written in EARS, a requirement already reads close to a criterion; Gherkin scenarios are criteria written as examples. And some criteria belong to the whole release rather than one requirement — the exit criteria of the UAT test plan.

Who writes acceptance criteria?

Usually the product owner or the business analyst drafts them, developers and testers sharpen them in refinement, and the person who will accept the work agrees them. In client work, that last step is the one that matters. As someone who does client work put it: “The requirements should be documented with clear deliverables, timeline and acceptance criteria” (r/web_design, 2025).

The criteria are what user acceptance testing checks at the end — see the UAT sign-off template — so they belong in the requirements sign-off at the start.

When acceptance criteria change

Requirements change, and their criteria have to change with them — everywhere they were copied. That is where it breaks:

If a change to the requirements is made then it has to be made in a couple of places, user acceptance criteria needs to be added associated with this requirement etc. etc. As this is done manually there have been occasions where the person updating the documents have updated it in the main document but neglected to update it in another.

— Project Management Stack Exchange, 2013

It is no better with AI tools. A team using BMAD alongside Jira: “Story statuses get out of date, acceptance criteria don’t match, and we’re constantly copying between systems” (BMAD #666). Another found that “a course correction can silently rewrite the acceptance criteria of a story that was already committed and merged” (BMAD #1930).

Three rules keep the criteria honest:

Criteria agreed for a version stay with that version. A change makes a new version, through a change request — not an edit.
Never rewrite the criteria of accepted work. They are the record of what was agreed.
When a criterion changes, find what was built and tested against the old one. Otherwise the tests check one thing and the requirement says another — spec drift.

Acceptance criteria checklist

Before a story goes into a sprint, or a requirement to the client:

Every criterion can be marked pass or fail by someone who did not write it.
Errors, empty states and limits have their own scenarios.
Nothing says how to build it.
What must not change is written down.
What is out of scope is written down.
The person who will accept the work has agreed them, and the requirement version is named.

Where Specroot fits

This is the problem Specroot works on: acceptance criteria that stay tied to the requirement and the version they were agreed for, and change only through a decision. Specroot for agencies and consultancies.