How to Write Acceptance Criteria That Teams Can Test

Learn how to write acceptance criteria for user stories: a step-by-step method, Given-When-Then and checklist examples, common mistakes, and a review routine.

By Val Narodetsky · Founder & CEO, Odesa.co

October 22, 2026

Good acceptance criteria are short, outcome-focused statements that a developer, a tester and a product owner can each read and judge the same way: pass or fail. To write them, start from the user story, list the observable outcomes, pick a format (a checklist or Given-When-Then), and review the draft with a business voice, a developer and a tester before work begins. The rest of this guide shows how, with examples you can adapt.

Odesa Co

Build With Clearer Engineering Teams

Odesa matches growth-stage companies with senior engineers for software projects, including flexible staff augmentation, recruitment, and custom development.

Book a discovery call

TL;DR

Acceptance criteria are the conditions a story must meet to be complete. They describe what the system does, not how it is built.
Every criterion should be binary and specific. If two people could disagree on whether it passed, rewrite it.
Use checklists for simple validations and Given-When-Then for behavior with context. Many teams combine both.
Write criteria with a product owner, a developer and a tester together, and finalize them just before the story enters a sprint.
Avoid button labels, pixel positions and implementation instructions. They make criteria brittle.

What acceptance criteria are, and what they are not
How to write acceptance criteria, step by step
Two formats: checklist and Given-When-Then
A worked example, from vague to testable
Review the criteria with the Three Amigos
Common mistakes and how to fix them
A quick checklist before you accept a draft
Our perspective
Where acceptance criteria meet release checks
FAQ
Sources

What acceptance criteria are, and what they are not

Acceptance criteria are the clear, concise and testable conditions a user story or increment of work must satisfy to count as complete. They state what success looks like for the user, not how engineers should produce it. In practice they work as a shared pass/fail contract between the business, development and QA.

Three neighboring terms get confused with them, so it helps to separate them.

The user story. It names who wants what and why. The criteria narrow the story into checkable behavior.
Requirements. A requirement is usually broader: a business rule, a compliance need, a capability. Acceptance criteria turn a requirement into the specific conditions for one piece of work. One requirement often yields criteria across several stories.
The definition of done. This is a team-wide quality bar that applies to every item (code reviewed, tests passing, deployed to staging). Acceptance criteria are specific to one story. A story is finished when it meets both.

Acceptance criteria are also not part of the Scrum Guide, which means there is no mandatory format. That is useful: you can choose whatever reduces ambiguity on your team.

How to write acceptance criteria, step by step

The method below works for a two-person startup team and for a distributed team spread across time zones.

1. Start with the user story

Write the story in a form your team already uses, such as “As a returning customer, I want to save my card so that checkout is faster.” The criteria must trace back to the value stated in the story. If a criterion does not serve that value, it belongs in another story.

2. List the observable outcomes

Ask: what will the user, or the system, visibly do when this works? Outcomes include what appears on screen, what is stored, what message is sent, and what is refused. Include the unhappy paths too: invalid input, expired sessions, empty states, permission failures.

3. Make each statement binary

A criterion either passes or fails. It cannot be half done. The Atlassian guidance recommends avoiding vague terms such as “fast” and focusing on outcomes. Replace adjectives with measurable conditions.

Vague	Testable
The page loads quickly	The search results page shows results within 2 seconds on the staging environment under the agreed test load
The form is user friendly	Each invalid field shows an inline message that names the problem, and the form keeps the other entered values
Passwords must be secure	Passwords under 12 characters are rejected with a message stating the minimum length

Note that the numbers in the right-hand column are examples. Your team sets them from your own product and users.

4. Choose a format

The next section covers the two common formats in detail.

5. Review with three perspectives

Draft criteria alone are a hypothesis. Test them in conversation before anyone writes code (see the review section below).

6. Finalize just in time

Do not write detailed criteria for stories months ahead. Scrum Alliance advises progressively elaborating items: refine each one again as it moves up the backlog, so you do not spend time on items that may be deprioritized. In practice, criteria get their final shape during backlog refinement or sprint planning.

Two formats: checklist and Given-When-Then

There is no single mandatory format. Atlassian’s community guidance suggests experimenting during retrospectives and judging formats by whether they reduce rework and ambiguity. If you want a view on how to compare approaches and choose one, a research-then-draft workflow with AI tools can speed up your first pass, as long as people still review and own the final wording.

Checklist (rule-oriented)

A checklist is a short bulleted list of conditions. It suits validations, permissions and simple functional rules.

Story: As an account admin, I want to invite teammates by email so that they can join our workspace.

An admin can enter one or more email addresses and send invitations.
Invalid email formats are rejected with an inline message before sending.
Each invited person receives an email with a link that expires after 7 days.
An expired link shows a message and offers to request a new invitation.
Users without admin rights do not see the invite option.
An address that already belongs to the workspace is not invited twice.

This list is easy to read and quick to scan in a ticket. Its weakness is context: it can hide which conditions depend on which state.

Given-When-Then (scenario-oriented)

The Given-When-Then template guides the writing of acceptance tests for a story: some context, an action, and an observable result. It is the usual choice for teams practicing behavior-driven development, and the format is often called Gherkin when it is written in a form tools can run.

Scenario: Expired invitation link

Given an invitation was sent 8 days ago
When the invited person opens the link
Then they see a message that the invitation has expired
And they can request a new invitation from the admin

Scenario: Non-admin cannot invite

Given I am signed in as a member without admin rights
When I open the team settings page
Then the invite option is not shown

Each scenario covers one behavior, which keeps failures easy to diagnose. Keep scenarios short: one “When” per scenario, and only the “Given” detail that affects the outcome.

Which one to pick

Situation	Better fit
Simple validations, field rules, permissions	Checklist
Behavior that depends on state or sequence	Given-When-Then
Stories that will become automated tests	Given-When-Then
Small team, fast-moving prototype	Checklist
Complex business rules with many cases	Both: scenarios for key flows, checklist for supporting rules

The Atlassian community guidance notes that many high-performing teams combine both: Given-When-Then for the key scenarios and a checklist for supporting validations.

A worked example, from vague to testable

Take this story: “As a shopper, I want to filter products by price so that I can find items in my budget.”

A first draft many teams write:

Filtering works.
The filter is easy to use.
Results update fast.

None of these can be tested the same way by two people. After a short conversation with a developer and a tester, the criteria become:

A shopper can set a minimum price, a maximum price, or both.
Only products whose price falls within the range (inclusive) are shown.
If the minimum is higher than the maximum, the shopper sees a message and the results do not change.
If no products match, the page shows an empty-state message and a link to clear the filter.
The selected range stays applied when the shopper moves to the next page of results.
The filter state is reflected in the page URL so the page can be shared.

The conversation produced three things the original draft missed: the boundary rule (inclusive), the invalid-range case, and persistence across pages. That is the real value of the exercise.

Review the criteria with the Three Amigos

The point of acceptance criteria is not documentation. Agile Alliance describes acceptance-test-driven work as people with different perspectives collaborating on tests before implementation begins, and the discussion itself is often worth more than the resulting text because it surfaces misunderstandings.

The usual pattern is the Three Amigos: a business representative such as the product owner, a developer and a tester. Each asks different questions:

Business: What problem does this solve, and what is out of scope?
Developer: What is technically hard, and what does this depend on?
Tester: What happens when input is missing, repeated, extreme or out of order?

If the group needs structure, Example Mapping (introduced at Agile2015 by Matt Wynne, as the same Agile Alliance page records) lets you lay out the story, its rules and concrete examples on cards. Rules that lack examples are not understood yet. Questions you cannot answer in the room go to the product owner before the story is accepted into a sprint.

If your team has no dedicated tester, that is the perspective most often missing, and it is the one that finds edge cases. You can borrow one. Our guide on UAT vs QA explains who owns which check and when, which helps you decide who should sit in that third seat.

Common mistakes and how to fix them

Prescribing how, not what

The biggest mistake practitioners describe is confusing criteria with technical instructions. “Use a modal with a dropdown backed by a Redis cache” dictates the solution. “The shopper can choose a shipping method and sees the updated total before paying” states the behavior and leaves the design to the people building it.

Over-specifying the interface

Agile Alliance warns against button labels and exact CSS positioning in acceptance tests, because cosmetic changes then break tests even when the business function is still correct. Write “the shopper can submit the order” rather than “the shopper clicks the green Buy Now button in the top right.” Put visual specifications in the design file and link it.

Writing too much, or too broadly

A story with 25 criteria is usually two or three stories. A story with two vague criteria is an invitation to rework. Aim for the smallest list that removes ambiguity. If you are constantly past eight or ten items, consider splitting the story.

Forgetting non-functional conditions

Performance, accessibility, security and logging often appear nowhere until they fail in production. Where they matter for a story, state them as measurable conditions, or point to the team-wide definition of done if they apply to every story.

Writing in isolation

Criteria written by one person and handed over tend to reflect one perspective. Bring the draft to refinement and expect it to change.

Treating criteria as frozen

If priorities shift, the criteria should shift with them. Writing them just in time avoids rewriting pages of text for a story that never ships.

A quick checklist before you accept a draft

Run each criterion through these questions:

Could two different people reach the same pass/fail verdict?
Does it describe an outcome the user or system shows, rather than an implementation choice?
Is it traceable to the user story’s value?
Does it avoid incidental UI detail that will change?
Are the error, empty and boundary cases covered?
Can a tester check it without asking the author what it means?

If any answer is no, rewrite before the story enters a sprint.

Our perspective

We place senior engineers and QA specialists in growth-stage teams, and the same pattern shows up often: delivery problems that look like engineering problems start as unclear expectations. A new engineer joining a team, whether in-house or through staff augmentation, is most productive when the story in front of them states what done looks like. Criteria that depend on tribal knowledge slow down every new person, and that cost is highest in distributed teams where a quick hallway question is not available.

Our view is that criteria should be written for the newest person on the team, not the most experienced. If someone who joined last week can read a story, build it, and know when to stop, the criteria are doing their job. We also encourage testers to be in the room early. Questions raised at refinement cost a few minutes. The same questions raised at release cost days.

Finally, we do not push a single format. Pick the one your team will actually keep current, and revisit it in a retrospective if rework keeps appearing.

— Editorial Team

Where acceptance criteria meet release checks

Criteria define what a story must do. A release check confirms that the finished product behaves that way for a real person, in the environment customers use. Teams that write precise criteria find that their release checks become quicker, because the checks come directly from the written conditions. Our software release checklist shows where these human checks sit among the gates before a release, and our bug triage process covers what to do with failures that do get through.

If you want an outside tester to apply your criteria before launch, we offer a Human Release Check at $1,500 one-off, with Release Check + Real Users from $2,500 one-off and Ongoing Human QA from $3,500 per month. If you need a senior QA or test automation engineer embedded in your team, see our QA and test automation engineers, or staff augmentation from $45 per hour. If your team lacks a facilitator for refinement sessions, a Scrum Master can run them.

FAQ

What should I write in acceptance criteria?

Write the observable conditions that must be true for the story to be complete: the main behavior, the error and empty cases, boundary values, and any measurable quality condition such as response time. Leave out implementation instructions and cosmetic detail. Each item should be something a tester can mark as pass or fail.

What is the difference between acceptance criteria and requirements?

A requirement is a broader need or rule the product must satisfy, often spanning many stories. Acceptance criteria are the specific, testable conditions for one story or increment that show the requirement is met in that piece of work. Requirements say what the product needs, and criteria say how you will know a particular slice delivers it.

How many acceptance criteria should a user story have?

There is no fixed number. Use as few as it takes to remove ambiguity, and treat a long list as a sign that the story may need splitting. Many teams find that a handful of well-chosen criteria is easier to keep current than a long list.

Do I have to use Given-When-Then?

No. Neither Scrum nor other frameworks require one format. Given-When-Then suits stateful behavior and automated tests, while checklists suit simple rules. Try both and keep the one that reduces rework and questions for your team.

Sources