Acceptance criteria are the specific, testable conditions a feature, user story or requirement must meet before the people who asked for it accept the work as done. A team writes them before the work starts, and each one gets a pass or fail result when the work is reviewed or tested.
When you review a story without acceptance criteria, the developer, the tester and the product owner each judge it against what they remember from planning, and those memories often differ. You can write the conditions as scenarios or checklists to make them testable, and on a regulated program you also link each one to the test that verifies it.
Why Do Acceptance Criteria Matter?
Acceptance criteria give a story a definition of finished that everyone checks against the same words. The conversation around a story is where a team builds a shared understanding of which scenarios it does and doesn’t need to account for. Each criterion is either met or not met, never partly fulfilled, so a reviewer can close the story with less debate.
A vague requirement becomes testable once you add acceptance criteria that can be measured. Adding concrete acceptance criteria is often much easier than writing a 100% unambiguous requirement.
For example, a tester who reads “the search should be fast” has nothing to measure. The tester can use a criterion with a response-time limit to decide what counts as a pass. Starting work before criteria are explicit is “one of the leading causes of unpredictability and re-work,” according to the Disciplined Agile guidance of the Project Management Institute (PMI).
When an AI coding agent implements a story, reviewers also use acceptance criteria to assess its output. On long-horizon Codex tasks, OpenAI has the agent work from a plan file with “Acceptance criteria + validation commands per milestone” and repair a failed validation before moving on (February 2026 guide). With Claude Code, a fresh subagent can review the diff against your spec and check that every requirement is implemented and the listed edge cases have tests.
What Formats Can Acceptance Criteria Take?
Teams write criteria as a Given-When-Then scenario or a rule-based checklist. A third notation, Easy Approach to Requirements Syntax (EARS), is for the underlying requirement the criteria verify. The right format depends on how your team writes and manages requirements: a team working from user stories usually writes scenarios or checklists, while a team that writes shall statements or EARS requirements writes the criteria beneath each requirement.
Write Scenario-Based Criteria in Given-When-Then
Given-When-Then describes one example of behavior as a context, an event and an outcome. A Given step is the initial context of the system, typically something that happened in the past. A When step is an event or an action, and a Then step is the expected outcome or result.
Keep each scenario to 3-5 steps, even when you do not automate it, and make the outcome something the system shows, such as a report, a user interface or a message. A record in a database is buried inside the system and doesn’t count as an observable outcome.
Use Rule-Based Checklists
A checklist states conditions that must hold, without describing a sequence. Checklist-style acceptance criteria are a list of outcomes that confirm a service has done its job and meets the user’s need (GOV.UK Service Manual). For the Register to vote service, one of three “it’s done when” outcomes is that the user knows where to send the form.
Checklists suit stories where the behavior is a set of constraints, such as field validation, display rules, limits and permissions. Both styles fit in one Gherkin file. Gherkin’s Rule keyword exists “to represent one business rule that should be implemented,” and the scenarios grouped under it are examples of that rule.
Where Does EARS Fit?
EARS is a notation for the requirement itself, and you write the acceptance criteria beneath it. Alistair Mavin developed EARS with colleagues at Rolls-Royce while analysing airworthiness regulations for a jet engine control system.
EARS gently constrains how a textual requirement is written. Its clauses follow a fixed order: precondition, trigger, system name and response.
An EARS requirement states what the system shall do. The acceptance criteria state the observations that would show it does. If your team already writes requirements this way, use the EARS notation guide to refine that practice, and keep the criteria under each requirement in Given-When-Then or checklist form.
How Do You Write Good Acceptance Criteria?
Someone who did not write a good criterion can decide to pass or fail without asking its author, and that is the test a requirements reviewer applies. This characteristic is Verifiable in version 4 of the International Council on Systems Engineering (INCOSE) requirements guide, which means a statement is structured and worded so that its realization can be verified to the approving authority’s satisfaction. Story-level criteria are verifiable when they meet these checks:
- Outcome before mechanism: The criterion states what the user or a connected system observes and leaves the build to the developers. Scenarios “should describe the intended behaviour of the system, not the implementation” (Cucumber). Implementation details should be omitted “unless there is rationale for constraining the design” (INCOSE rule R31).
- A number where the wording is vague: Words such as “fast,” “user-friendly,” “maximum” and “minimum” need specific quantities (INCOSE rule R34). In INCOSE’s example, “The <SOI> shall use minimum power” becomes “The <SOI> shall consume less than or equal to 50W of mains power.”
- One condition per criterion: “Use a separate clause for each condition or qualification” (INCOSE rule R11). A bundled criterion can be only partly satisfied, so the reviewer cannot assign one pass or fail result.
- An outcome someone can see: Each Then names a screen, message, report or measurement, because that is what the tester checks.
- The failure paths: Criteria cover invalid input, missing data and blocked states alongside the success case. A story that covers only the success case leaves the error behavior undefined.
- No escape clauses or absolutes: Criteria should omit phrases such as “as appropriate,” “if necessary” and “where possible” (INCOSE rule R8). They should also omit “unachievable absolutes such as 100% reliability” (INCOSE rule R26).
- A tester’s read: Before work starts, the person who will verify the story sketches a test from each criterion. If the tester can’t test a criterion, ask the author to reword it.
Karol Frühauf argues in the RE Magazine of the International Requirements Engineering Board (IREB) that criteria written as “the list of test cases the requirements engineer thinks should be executed” are test cases, not acceptance criteria. Criteria define what acceptance means, and one criterion may need several test cases.
What Do Good Acceptance Criteria Examples Look Like?
A good acceptance criteria example names an observable result and the conditions under which it counts as a pass, whether it checks a simple software story or a medical device design input.
Example: Check a Login-Gated Account Balance (Given-When-Then)
For a login-gated balance, check both whether a user can see the balance after logging in and whether it remains hidden before login. For a mobile banking feature, these Gherkin scenarios from the Cucumber project cover the two login states:
Feature: Some important feature
Scenario: Do not show balance if not logged in
Given I am not logged on to the mobile banking app
When I open the mobile banking app
Then I can see a login page
And I do not see account balance
Scenario: Show balance on the accounts page after logging in
Given I have just logged on to the mobile banking app
When I load the accounts page
Then I can see account balance for each of my accounts
The two scenarios test opposite states of the same rule, and each Then names something the user can see, a login page or a balance, instead of a session record inside the system. Use both scenarios when reviewing the feature so that showing the balance after login does not substitute for checking that it is hidden before login.
Example: Define Search Results (Rule-Based Checklist)
A search story is mostly rules, so a checklist is easier to read than scenarios. A full checklist built around a sample criterion from a Scrum.org article, “The search feature must return results in batches of no greater than twenty-five items,” could read:
- Batch size: The search returns no more than twenty-five items per batch.
- Empty result: A search with no matches shows a “no results found” message, and the search box keeps the entered term.
- Match rule: A result appears only if its title or description contains every word in the search term.
- Next batch: Selecting the control for more results loads the next batch without repeating any item already shown.
Use searches with no matches and with more than twenty-five matches to check the empty-result and next-batch rules. Check the title and description matches separately from batch size, so a search that returns the right number of results still has to show it returned the right items.
Example: Verify an Avionics Thrust Reverser Function (EARS Requirement With Scenario Criteria)
When an embedded requirement is already written in EARS, the criteria refine it. For the avionics requirement “While the aircraft is on ground, when reverse thrust is commanded, the engine control system shall enable reverse thrust,” a scenario-based criterion could read:
Scenario: Reverse thrust commanded while on ground
Given the aircraft is on ground
When reverse thrust is commanded
Then the engine control system permits reverse thrust
To test how quickly the system permits reverse thrust, ask the engineer who owns the system requirement to specify a response-time value. Reverse thrust commanded in flight needs its own requirement, typically in the unwanted-behaviour (If-Then) pattern, before you write a criterion for it. To make the test conditions reproducible, define every term in a glossary or data dictionary (INCOSE rule R4). For this test, define “on ground” in a way the test rig can reproduce.
Example: Weigh a Portable Medical Device (Hardware Design Input)
Hardware criteria are often a measured value with a tolerance. In an FDA training example written for the former Quality System Regulation, a portable device is one the end user must hand carry, and weight is the criterion to measure. The first specification is five pounds plus or minus one kilogram, so the mixed units have to be resolved to one. The corrected design input is “five pounds, plus or minus one pound.”
As an acceptance criterion, that becomes: given a production-equivalent unit, when the unit is weighed on a calibrated scale, then the recorded weight is between four and six pounds. On a medical device program, you record that criterion with the design output it checks.
How Are Acceptance Criteria Different From the Definition of Done and From Requirements?
Acceptance criteria belong to one backlog item, while the Definition of Done applies to every item, and the requirement states the need that both are checked against.
How Acceptance Criteria Differ From the Definition of Done
Developers must meet the Definition of Done for every Increment, rather than negotiate it separately for each story. The Definition of Done is “a formal description of the state of the Increment when it meets the quality measures required for the product” (Scrum Guide, November 2020 edition). If your company has no standard of its own, the Scrum Team creates one for the product, and an item that misses it “cannot be released or even presented at the Sprint Review.”
Scrum doesn’t require acceptance criteria, but they are a complementary practice that helps create transparency. The Definition of Done cannot be negotiated down, and acceptance criteria can be. A Definition of Done item such as “Unit tests are written for all code, achieving 80% code coverage” applies to every story in the Increment.
How Acceptance Criteria Differ From Requirements
A requirement states what the product shall do, and acceptance criteria state how you’ll know it does. Acceptance criteria “complete the definition of the requirement,” and are also known as fit criteria. In a story-only backlog the story is the requirement. On a systems program, write the criteria under a shall statement like the ones in the functional requirements examples guide.
In requirements verification and validation, teams choose among four methods: inspection (including peer review), analysis (including modeling and simulation), demonstration and test. You might check a label’s wording by inspection, while a thermal limit may need analysis.
The table sets an item’s acceptance criteria beside the product-wide Definition of Done and the underlying requirement.
| Acceptance criteria | Definition of Done | Requirement | |
|---|---|---|---|
| Applies to | One backlog item or requirement | Every item in the Increment | One system, subsystem or software need |
| Written by | Whoever knows the need best, with the product owner accountable | The Scrum Team, or your company as a standard | Systems engineers and quality and regulatory staff, per program process |
| Answers | How will we know this item works? | Does this work meet our quality standard? | What must the product do? |
| Negotiable per item | Yes | No | Through change control |
You return an item that misses the Definition of Done to the Product Backlog (Scrum Guide). You can, by contrast, negotiate an unmet acceptance criterion.
Who Writes Acceptance Criteria, and When?
The product owner is accountable for acceptance criteria. The whole team contributes to writing them during backlog refinement, before the sprint in which developers implement the story.
Who Writes Acceptance Criteria?
The Product Owner is accountable for “creating and clearly communicating Product Backlog items” and may delegate that work, but “the Product Owner remains accountable” (Scrum Guide). Who writes the words varies by team. The person who knows the most about the requirement writes the acceptance criteria, whether that’s a product owner, business analyst, software tester or quality assurance specialist.
To write criteria together, use the Three Amigos pattern. Team members representing the business perspective ask “What problem are we trying to solve?” and developers ask “How might we build a solution to solve that problem?”
Testers ask “What about this, what could possibly happen?” Answering that question gives you criteria for failure paths as well as the success case. The test team should develop or review the acceptance criteria.
When Do Teams Write Acceptance Criteria?
In agile requirements management, teams draft criteria during backlog refinement and finalize them before the sprint. Add acceptance criteria as a story gets closer to implementation. Iteration planning in Disciplined Agile takes as an input a backlog “preferably elaborated (refined, sized, and with initial-acceptance criteria).” With Acceptance Test-Driven Development (ATDD), team members write acceptance tests together before they implement the functionality.
To change a criterion in the Product Backlog, convince the Product Owner (Scrum Guide). On an agile team where only the current wording matters, that agreement can be enough without a separate review step. On a regulated program, the criterion’s history matters as much as its current text.
How Do You Link Acceptance Criteria to Verification and Traceability in Regulated Programs?
In a regulated program each acceptance criterion is a verification commitment. Each criterion needs a test that checks it, a link back to the requirement it refines, and a record of who changed it and why.
Check What Your Standard Requires
If you develop medical devices, FDA’s Quality Management System Regulation (QMSR), 21 CFR Part 820, took effect on 2 February 2026. Under the QMSR, design outputs must contain or reference acceptance criteria, and you review, verify or validate as appropriate, and approve each design change before you implement it. For software, FDA’s software validation guidance also recommends that “A software requirements traceability analysis should be conducted to trace software requirements to (and from) system requirements and to risk analysis results.”
Other regulated domains require the same evidence and change records, using their own terms. DO-178C made traceability explicit for test results, test procedures and test cases through to requirements. For road vehicles, ISO 26262-8 sets requirements for configuration management and change management as supporting processes.
Trace Each Criterion to the Test That Verifies It
You link each criterion to the requirement it refines and to the test case that checks it, so an assessor can trace a requirement to its evidence. For a test engineer to write that test case without asking the author, the criterion names an outcome the tester can measure and a verification method, such as test, inspection or analysis.
One criterion may need several test cases, so the criterion links to each of them. A criterion with no linked test, or a test linked to no criterion, is then visible in the trace before the verification review starts.
Keep Each Criterion’s Change History
If you store criteria only in a ticket’s description field and the tracker keeps no history of that field, an edit can replace the wording a test was written against, with no record linking the two. To keep a record of each edit, a changed criterion goes through the same review and approval as a changed requirement, and someone reassesses each linked test before its next run.
Use the trace links to identify which tests need review when a criterion changes. Keep the earlier wording and the approval record available for that review.
Keep Trace Links Intact Through Verification and Validation
Trace links stay intact when someone re-checks them after every edit across the program’s backlog. Jama Connect® is a web-based requirements management and traceability platform for complex, regulated product development, and it stores requirements and the test cases that verify them as linked items, each with its own version history. Use those links and version histories during validation to check that each criterion, its test and the recorded result refer to the same requirement version.
Keeping criteria, tests and requirements linked is one way to shorten validation. SPAN reduced system validation timelines by up to 25% and reduced reviews to two cycles. Linking shortens validation only when the criterion itself is testable; otherwise the validation team still writes the test from scratch.
How Jama Connect Supports Traceable Acceptance Criteria
To keep acceptance criteria traceable, Jama Connect links each test case to the requirement whose criteria it checks. When that requirement changes, suspect links flag every linked test case for review. Item version history records who changed a field, when and why, and Review Center collects approvals with electronic signatures. With Traceable Agile™, you store stories and tasks in a supported issue tracker while Jama Connect Interchange™ synchronizes those items with Jama Connect, where they trace to requirements.
To help write criteria the test team can verify, Jama Intelligence evaluates requirement text against 30 of the 40 INCOSE rules and flags vague terms, passive voice and ambiguous language. It also checks requirements against the six EARS patterns. Its test case generation drafts test cases with steps from a requirement, and the trace link is created only when the engineer reviews and accepts a draft. Jama Intelligence is an add-on for Jama Connect Cloud, and work done with AI inside Jama Connect is versioned and documented as AI-generated.
Writing Acceptance Criteria Your Team Can Test and Trace
The easiest moment to make a criterion verifiable is the refinement session where someone writes it, because the tester, the developer and the product owner are already discussing the story. A criterion the test team rewrites weeks later exists in two versions, and a regulated program needs a record of both.
Link a handful of stories’ criteria to their requirements and tests to check whether your change process works when a criterion changes. A free 30-day trial of Jama Connect gives you a place to run that check on your own backlog.
Frequently Asked Questions About Acceptance Criteria
Should acceptance criteria cover performance, security and other non-functional needs?
Yes, where the need applies to that story. Quality requirements drive many of the acceptance criteria for functional requirements. Expectations that apply to every story, such as regulatory documentation or a product quality standard, belong in the Definition of Done.
Can a story be done if it misses some acceptance criteria?
Under Scrum, developers can still include the work in an Increment if it meets the Definition of Done.
How many acceptance tests does a story need?
At least one, and a story can have several. A story with several criteria usually needs several tests. A Scenario Outline can cover many value combinations with one scenario and an Examples table.
