·
8 min
How to write acceptance criteria: formats, banking examples and the path to a test
Roman Kirchmeier - Autemos
Acceptance criteria (AC) are the conditions a user story must meet for stakeholders to accept it, and the ISTQB syllabus treats them as test conditions. They define what a test case will check later, before any code exists. The syllabus names two formats: scenario-oriented with Given/When/Then, and rule-oriented as a checklist or table. The examples below come from a bank's payment flow, a transfer limit and a four-eyes approval, and both include the negative cases that carry the most risk for a bank.
TL;DR: AC describe when a user story is accepted, and ISTQB CTFL 4.5.2 treats them as test conditions. Write them scenario-oriented (Given/When/Then) or rule-oriented (a table), and always with positive and negative cases. AI can draft tests from them: in one industrial study, 60% of generated test flows were usable as generated (Ferreira et al., 2025).
Figure 1: In the 3 C's model, acceptance criteria are the Confirmation of a user story.
What are acceptance criteria?
Acceptance criteria are conditions a work product must satisfy for stakeholders to accept it; in agile teams they belong to a user story. The official ISTQB glossary defines them as “The criteria that a work product must satisfy to be accepted by the stakeholders.” The German glossary lists Abnahmekriterien as a synonym.
The ISTQB Foundation Level syllabus 4.0.1 concludes: “acceptance criteria may be viewed as the test conditions that should be exercised by the tests” (ISTQB CTFL 4.0.1, 2024). The glossary defines a test condition as “A testable aspect of a component or system that is intended to be tested.” The criteria say what gets tested. The test case says how.
The syllabus places AC in Ron Jeffries' 3 C's: Card, Conversation, Confirmation. Confirmation stands for the criteria (ISTQB CTFL 4.0.1, 2024). Bill Wake's INVEST gives the practical check: writing a story card carries “an implicit promise” that the author knows the need well enough to write a test for it (Wake, 2003).
Which two formats does the ISTQB syllabus name?
The ISTQB syllabus names two formats for AC: “Scenario-oriented (e.g., Given/When/Then format used in BDD…)” and “Rule-oriented (e.g., bullet point verification list, or tabulated form of input-output mapping)” (ISTQB CTFL 4.0.1, 2024). Either format is valid if the criteria are well-defined and unambiguous.
Figure 2: Scenario-oriented for flows, rule-oriented for rules with many combinations.
Scenario-oriented: transfer with a daily limit
The user story reads: “As a retail customer, I want to approve transfers in online banking up to my daily limit, so that I can pay bills without calling the bank.”
No. | Given | When | Then |
|---|---|---|---|
1 (positive) | daily limit CHF 10,000, CHF 2,000 already transferred today | the customer approves CHF 5,000 | the payment is executed, the remaining limit shows CHF 3,000 |
2 (boundary) | same as no. 1 | the customer approves CHF 8,000 | the payment is executed, the remaining limit shows CHF 0 |
3 (negative) | same as no. 1 | the customer approves CHF 8,000.01 | the payment is rejected, the message states the remaining limit of CHF 8,000, the account is not debited |
4 (negative) | the account is blocked | the customer approves CHF 100 | the payment is rejected, the message refers to the block |
Row 2 tests the boundary, row 3 the first invalid amount just above it. Our Gherkin syntax guide covers keywords, Scenario Outlines and example tables. For team collaboration around this format, see BDD testing.
Rule-oriented: four-eyes approval for corporate payments
The user story reads: “As a compliance officer, I want corporate payments of CHF 50,000 or more to need a second approval, so that no single person can release large amounts alone.”
Rule | Input | Expected result |
|---|---|---|
R1 | payment of CHF 49,999.99 with one approval | the payment is executed |
R2 | payment of CHF 50,000 with one approval | status “awaiting second approval”, no execution |
R3 | second approval by the person who entered the payment | the approval is rejected |
R4 | second approval by a person without the “approver” role | the approval is rejected |
R5 | second approval by a second authorized person | the payment is executed, both approvals are logged with user and timestamp |
The rule format fits when a business rule has many combinations of amount, role and person. Three of the five rules describe what the system must prevent: for a bank, the highest-risk rows and the later negative tests.
How do you write good acceptance criteria?
Good criteria are unambiguous, testable and describe positive and negative scenarios. ISTQB CTFL 4.5.2 asks for criteria that are “well-defined and unambiguous” and lists “Describe both positive and negative scenarios” among their purposes (ISTQB CTFL 4.0.1, 2024). Unclear requirements cost projects. In the 2014/15 NaPiRE survey of 228 companies in 10 countries, incomplete or hidden requirements were the most frequently named problem (109 companies, 48%). 43 of those companies saw it as a cause of project failure (NaPiRE study, 2017).
A checklist for writing them:
Observable result: Each criterion ends with something a test can see, for example a message, a status or an account balance.
Concrete values: “CHF 8,000” in place of “large amounts”, “within 2 seconds” in place of “fast”.
One behavior per criterion: Two rules in one sentence make two criteria.
Negative cases: invalid amounts, missing permissions, blocked accounts and values just past the boundary.
Business language: Describe what happens in business terms (“the payment is rejected”). Click paths and button colors belong in the test case.
A manageable number: The QS-Baukasten of Germany's Federal Office of Administration gives 4 to 8 criteria per story as a rule of thumb (BVA QS-Baukasten, 2024).
The syllabus sets the testing order: “After the positive test cases are done, the team should perform negative testing” (ISTQB CTFL 4.0.1, 2024). That needs the negative cases named up front; negative testing shows how to find invalid inputs systematically. In acceptance test-driven development (ATDD), test cases are written before implementation, and “The acceptance tests then become executable requirements.”
How do acceptance criteria differ from the Definition of Done?
AC apply to one user story and describe its business behavior; the Definition of Done applies to every Increment and describes quality measures that must always be met. The Scrum Guide calls the DoD “a formal description of the state of the Increment when it meets the quality measures required for the product” (Scrum Guide 2020, 2020).
Neither AC nor user stories appear in the 2020 Scrum Guide. Both come from Extreme Programming circles, for example Ron Jeffries' 3 C's model (Jeffries, 2001), and today the ISTQB syllabus describes them.
Aspect | AC | Definition of Done |
|---|---|---|
Scope | one user story | every Increment, all backlog items |
Source | Extreme Programming, ISTQB CTFL 4.5.2; not in the Scrum Guide 2020 | Scrum Guide 2020 |
Content | business behavior, rules, boundaries | quality measures, e.g. code review, regression tests, documentation |
Example | “A payment above the remaining limit is rejected.” | “All automated regression tests pass.” |
Who sets it | Product Owner with development and testing | Scrum Team or the organization as a minimum standard |
An item such as “code review done” belongs in the DoD once, instead of in every story. More on building a DoD: Definition of Done.
How does a criterion become an automated test?
Acceptance criteria become an automated test in seven steps, from the story through test cases and an approved test flow to the link in Jira and Xray. The order follows the ISTQB chain of test analysis (test conditions), test design (test cases) and test implementation (test scripts) (ISTQB CTFL 4.0.1, 2024).
Figure 3: Seven steps from criterion to an approved, traceable test.
Write the story: role, goal and benefit in the form “As a [role], I want [goal], so that [benefit]”.
Agree on criteria in a workshop: Product Owner, developers and testers agree on positive and negative criteria before implementation.
Pick a format: Given/When/Then for flows, a table for rules with many combinations.
Derive test cases: each criterion produces one or more test cases with preconditions, test data and expected results.
Automate: a tool or an engineer turns the test cases into executable tests.
Review and approve every step: a person compares the draft with the criteria before it runs.
Run and link: The pipeline starts the tests. Results land on the Jira ticket, where the story's coverage is traceable.
Mike Cohn on step 4: criteria are usually higher-level than test cases, and a single criterion “may lead to many tests.” (Mountain Goat Software, 2026).
Autemos is AI-assisted software for functional test automation across Web, Mobile, API and Desktop. Its AI Recorder drafts an executable test workflow from a Jira ticket, a user story or a plain-text test case. The team approves every AI-generated step before it runs.
For step 7, the Autemos connector for Jira and Xray syncs test cases and executions in both directions. Per Xray's documentation, Cucumber tests linked to a Jira story count in that story's requirement coverage (Xray Traceability Report, n.d.). The ticket then shows which criteria were tested and passed.
When several criteria form one continuous business flow, such as entering, approving and booking a payment, a dedicated test scenario makes sense. Formal business sign-off is covered under acceptance testing.
How well does AI generate tests from written criteria?
AI produces usable test drafts from acceptance criteria written as Gherkin scenarios, and a person still has to review them. In an industrial study with GPT-4 Turbo, 60% of generated test flows were usable as generated (Ferreira et al., IEEE/ACM AST, 2025). Participants rated 92% of the test flows as helpful and the generated Gherkin scenarios as helpful 95% of the time.
Figure 4: 60% of AI-generated test flows were usable as generated (Ferreira et al., 2025).
Outcome of generated test flows | Share |
|---|---|
usable as generated | 60% |
usable after minor fixes | 8% |
regenerated with more input | 24% |
discarded | 8% |
The study comes from a single company. The authors say LLMs help “with appropriate tooling and supervision.”
A preprint from RMIT University with 500 user stories shows what quality depends on. All three LLMs tested produced worse tests when they received only the user story. With detailed requirements, quality held up (Rathnayake et al., preprint, 2026).
For teams, this means an AI can only test what the criteria state. If the negative case isn't written down, the model has nothing to work from.
What mistakes do teams make when writing criteria?
Typical mistakes with acceptance criteria are vague terms, missing negative cases and click instructions with no business rule. Watch for these in refinement:
Only the happy path is described.
“Fast”, “user-friendly” or “correct” appear with no measurable value.
DoD items like “code review done” repeat in every story.
Teams write the criteria after implementation, so they describe what was built.
One story has 15 criteria and could be split into three stories.
The criteria change during the sprint, the linked tests don't.
Femmer et al. detected so-called requirements smells automatically with “average precision of 59% at an average recall of 82%” (Femmer et al., 2017). A team review is still needed.
Frequently asked questions
Who writes the acceptance criteria for a user story?
The Product Owner usually owns them, and they work best when written together with developers and testers. The ISTQB syllabus describes a specification workshop where the team analyzes the story and records criteria before implementation begins.
How many criteria does a user story need?
The rule of thumb is 4 to 8 criteria per story, per the QS-Baukasten of Germany's Federal Office of Administration (BVA, 2024). It's a practitioner rule, not a standard. Many more usually means the story should be split.
Are acceptance criteria part of the Scrum Guide?
No, the 2020 Scrum Guide mentions neither AC nor user stories (Scrum Guide 2020, 2020). It defines the Definition of Done as the commitment for the Increment. AC are a complementary practice that the ISTQB syllabus describes in section 4.5.2.
Are acceptance criteria the same as test cases?
No, AC are test conditions and say what gets checked; test cases say how, with preconditions, inputs and expected results. The current ISTQB glossary says a test case is “developed based on test conditions.” One criterion often yields several test cases.
Can AI write acceptance criteria?
Language models can produce drafts, and responsibility for the criteria stays with the team. In the Ferreira et al. study, participants rated AI-generated Gherkin scenarios as helpful 95% of the time (Ferreira et al., 2025). Autemos doesn't write them; it turns existing stories and criteria into executable tests, with every step approved.
Conclusion
Acceptance criteria are the test conditions of a user story. Write them before implementation, with concrete values and negative cases. Given/When/Then fits flows, a table fits rules with many combinations. Quality measures for every story belong in the Definition of Done.
For automation, test quality depends on the criteria. In the study by Ferreira et al., 60% of AI-generated test flows were usable as generated; the rest needed fixes, more input or were discarded. Per-step approval and the Jira and Xray link show later which criterion was tested, how, and with what result.
To see how Autemos turns your Jira stories into approved, traceable tests, book a demo.
