Acceptance criteria are the conditions a piece of work must satisfy to be considered complete and accepted. They turn a vague feature request into a short, testable checklist that tells developers what to build, tells QA what to verify, and tells everyone else what "done" actually means. Written well, acceptance criteria remove the argument at the end of a sprint about whether a story is finished.
They live inside your product docs, so they sit next to the rest of your spec trail. Acceptance criteria attach to a user story template, get rolled up into a PRD template, and feed straight into the test plan template your QA team writes from. On larger features, they also anchor the software requirements specification and the engineering design doc template that follows. This guide covers what acceptance criteria are, the two main formats, worked examples, how to write them, and how they differ from the definition of done.
What is acceptance criteria?
Acceptance criteria are a set of clear, testable statements that define the conditions a user story must meet to be accepted by the product owner or customer. Each statement describes an outcome, not an implementation. It says what the user should be able to do or see, and leaves the how to the engineers.
The point is agreement before code gets written. When the team agrees on acceptance criteria during backlog refinement, everyone works toward the same target. QA knows what to test, the developer knows when to stop, and the product owner knows what they will inspect at review. There is no guessing.
Good acceptance criteria share a few traits. They are specific enough to pass or fail with no debate, written in plain language a non-technical stakeholder can read, and scoped to a single story rather than the whole product. If a criterion needs a meeting to interpret, it is not finished yet.
Why acceptance criteria matter
Skip acceptance criteria and you get the classic sprint-review surprise: the developer built what they thought the story meant, and the product owner wanted something else. Both were right, because nobody wrote down the target. Acceptance criteria are the shared contract that prevents that gap.
They pay off in four ways:
- Fewer rework loops. A clear definition of what "done" looks like catches scope gaps during planning, when a fix costs a sentence, instead of at review, when it costs a sprint.
- Faster, cleaner QA. Testable criteria convert directly into test cases. QA does not have to reverse-engineer intent from a one-line ticket.
- Honest estimates. A story with real acceptance criteria is easier to size, because the team can see the actual scope instead of guessing at hidden edge cases.
- Less scope creep. Criteria draw a boundary. Anything outside them is a separate story, not an ambush added mid-sprint.
The two main acceptance criteria formats
Most teams write acceptance criteria in one of two formats. Both are valid. The right one depends on the story and, honestly, on team preference. Many teams mix them, using scenarios for behavior-heavy stories and checklists for simpler ones.
Given / When / Then (Gherkin)
The scenario-based format uses the Given/When/Then structure, borrowed from behavior-driven development and the Gherkin syntax used by tools like Cucumber. Each scenario spells out a starting context, an action, and the expected result:
Given [some initial context or state],
When [the user performs an action],
Then [a specific, observable outcome should occur].
A real example for a login story:
Scenario: Successful login
Given I am a registered user on the login page,
When I enter a valid email and password and click Sign In,
Then I am taken to my dashboard.
Scenario: Wrong password
Given I am a registered user on the login page,
When I enter a valid email and an incorrect password,
Then I see the message "Email or password is incorrect"
And I stay on the login page.
The Given/When/Then format shines when behavior depends on state or when a story has several distinct paths (success, failure, edge case). Each scenario maps one-to-one to an automated test, which is why QA and engineering teams tend to prefer it. The tradeoff is verbosity: simple stories can feel over-documented in this format.
Rule-oriented checklist
The second format is a plain list of rules or conditions the story must satisfy. No scenario structure, just verifiable statements:
Acceptance criteria:
- Password reset email arrives within 60 seconds of the request.
- Reset link expires after 24 hours.
- Reset link works only once.
- New password must be at least 8 characters.
- User sees a confirmation message after a successful reset.
Checklists are faster to write and easier to scan, which makes them a good default for straightforward stories and for teams whose stakeholders are not steeped in agile syntax. The risk is that a bare list can drift into vagueness ("works well," "looks good"), so each item still needs to be objectively testable. If you cannot write a pass/fail test for a line, rewrite it.
Here is how the two formats compare:
| Dimension | Given / When / Then | Rule-oriented checklist |
|---|---|---|
| Best for | Behavior with multiple paths or states | Simple, condition-based stories |
| Readability | Structured, slightly verbose | Fast to scan |
| Maps to automated tests | Directly, one scenario per test | Needs interpretation |
| Learning curve | Higher (BDD/Gherkin syntax) | Low, anyone can read it |
| Risk | Over-documenting simple stories | Drifting into vague statements |
Acceptance criteria examples
Abstract rules only get you so far. Here are three worked examples, each pairing a real user story with acceptance criteria you could drop into a ticket today.
Example 1: Product search (checklist format)
User story: As a shopper, I want to search products by name so I can find items without browsing every category.
Acceptance criteria:
- The system returns all products whose name exactly matches the search term.
- The system returns partial matches once the user types at least three characters.
- Results show product name, image, and price in a single row.
- Results paginate at 20 items per page.
- An empty result set shows a "No products found" message with a link back to all categories.
Example 2: Password reset (Given / When / Then)
User story: As a registered user, I want to reset my password so I can get back into my account after forgetting it.
Acceptance criteria:
Scenario: Request a reset link
Given I am on the "Forgot password" page,
When I enter the email tied to my account and submit,
Then I receive a reset email within 60 seconds.
Scenario: Use an expired link
Given I received a reset link more than 24 hours ago,
When I click that link,
Then I see "This link has expired" and an option to request a new one.
Scenario: Set a new password
Given I opened a valid reset link,
When I enter a password of at least 8 characters and confirm it,
Then my password updates and I see a success confirmation.
Example 3: Export report (checklist format)
User story: As an admin, I want to export activity reports so I can share usage data with stakeholders.
Acceptance criteria:
- The Reports page has an Export button visible only to admin roles.
- Reports export in both CSV and PDF.
- The export respects the currently applied date-range and user-type filters.
- Exports of up to 10,000 rows complete within 10 seconds.
- A failed export shows an error message and does not download a partial file.
Notice that every criterion in all three examples is a fact you can check. There is no "the page should look nice." Vague adjectives are the enemy of good acceptance criteria.
How to write acceptance criteria
Writing acceptance criteria is a short, repeatable process. Run it during backlog refinement, before the story enters a sprint, not after.
- Start from the user story. The criteria exist to satisfy the story's goal. Reread the "so that" clause and make sure your criteria deliver that value.
- List the outcomes, not the steps. Describe what the user should be able to do or see. Leave the technical approach to the engineers who will build it.
- Cover the unhappy paths. Most weak criteria only describe success. Add the empty state, the validation error, the expired token, the permission denial. Bugs hide in the paths nobody wrote down.
- Make each line testable. If you cannot imagine a pass/fail test for a criterion, it is too vague. Replace "loads fast" with "loads in under two seconds."
- Keep each criterion independent. One condition per line. When criteria depend on each other to make sense, testing and debugging both get harder.
- Review as a team. The product owner brings intent, engineering brings feasibility, QA brings the edge cases. Acceptance criteria written by one person alone tend to miss one of those three.
A useful gut check: hand your criteria to someone who was not in the planning meeting. If they can build or test the story without asking you a question, the criteria are done. If they come back with questions, those questions are your missing criteria.
Acceptance criteria vs definition of done
These two get confused constantly, but they operate at different levels. Acceptance criteria are specific to one story. The definition of done is a global standard that applies to every story your team ships.
Acceptance criteria answer "did we build the right thing for this feature?" The definition of done answers "did we meet our quality bar for all work?" A story can pass its acceptance criteria and still fail the definition of done if, say, the code has no tests or the docs were not updated.
| Acceptance criteria | Definition of done | |
|---|---|---|
| Scope | One user story | Every story the team ships |
| Answers | Did we build the right thing? | Did we meet our quality bar? |
| Written by | Product owner plus team, per story | The team, once, and reused |
| Changes | New set for every story | Stable across the backlog |
| Example item | "Reset link expires after 24 hours" | "Unit tests pass and code is reviewed" |
Both are gates. A story ships only when it passes its own acceptance criteria and clears the team's definition of done. Skipping either one is how half-finished work sneaks into a release.
Who writes acceptance criteria, and when
Acceptance criteria are a team effort, though one person usually drives the first draft. The product owner typically writes the initial version because they hold the customer context and the "why." Engineering then pressure-tests it for feasibility and hidden edge cases, and QA adds the conditions they would test against.
Timing matters as much as authorship. Write acceptance criteria during backlog refinement, before the story is pulled into a sprint. That gives the team a chance to size the story accurately and to catch scope problems while they are still cheap. Criteria written mid-sprint, after work has started, usually mean the story was not ready to begin with.
Because acceptance criteria live in the same spec docs as your requirements and user stories, keeping them in one searchable place matters more than the tool you pick. Teams that scatter criteria across tickets, Slack, and personal notes lose them. If your specs and product docs already live on a hosted docs site, tools like Docsio can keep the story, its criteria, and the surrounding context in one place your whole team can read.
Common acceptance criteria mistakes
The same problems show up on team after team. Watch for these:
- Writing implementation instead of outcome. "Use a Redis cache for the search index" is a technical decision, not an acceptance criterion. State the outcome ("search results return in under one second") and let engineers choose the how.
- Only covering the happy path. Success cases are easy. The value is in the error states, empty states, and permission checks. Those are where real users break things.
- Vague, untestable language. "Fast," "intuitive," "user-friendly," and "looks good" cannot pass or fail. Every criterion needs a concrete, checkable threshold.
- Bundling too much into one story. If a story needs fifteen criteria across unrelated behaviors, it is probably several stories wearing a trenchcoat. Split it.
- Writing them after development starts. Criteria are a planning tool. Write them late and they become a rationalization of whatever got built, not a target the team aimed at.
Acceptance criteria FAQ
Answered below are the questions teams ask most about acceptance criteria.
What is an example of acceptance criteria?
A simple example for a login story: "Given a registered user enters a valid email and password, when they click Sign In, then they are taken to their dashboard." Another: "The password reset link expires after 24 hours." Each states a testable condition the feature must meet to be accepted as complete.
What is the difference between acceptance criteria and definition of done?
Acceptance criteria are specific to one user story and describe what that feature must do to be accepted. The definition of done is a global quality standard that applies to every story, covering things like passing tests, code review, and updated docs. A story must satisfy both to ship.
Who writes acceptance criteria?
Acceptance criteria are usually drafted by the product owner, who holds the customer context, then refined with the development team and QA. Engineering checks feasibility and edge cases, while QA adds the conditions they will test. The final set reflects all three perspectives rather than one person's assumptions.
When should acceptance criteria be written?
Write acceptance criteria during backlog refinement, before the story enters a sprint. Defining them early lets the team estimate the work accurately and catch scope gaps while they are cheap to fix. Criteria written after development begins tend to describe what was built rather than what was intended.
What makes good acceptance criteria?
Good acceptance criteria are clear, testable, and outcome-focused. Each one can pass or fail with no debate, uses plain language any stakeholder can read, covers both success and failure paths, and describes what the user experiences rather than how it is coded. If a criterion needs interpretation, it is not finished.
Acceptance criteria are one of the cheapest ways to improve delivery quality, since they cost a few minutes in planning and save whole sprints in rework. Pick the format that fits the story, keep every line testable, and write them before code starts. Store them next to your user stories and requirements so the whole team works from the same source, and your sprint reviews stop ending in surprise.