Acceptance Criteria Formats and the 3C

Acceptance criteria formats are the ways a team writes down what "done right" means for one backlog item: rule statements ("The user can…"), Given/When/Then scenarios, example tables, use cases or a link to an agreed design. My take is that the format matters less than the 3C idea behind it. Once the team agrees on the card, everything on the card works as acceptance criteria [1, 2].

Last verified: October 2026

What acceptance criteria are

Acceptance criteria are the requirements, outcomes or conditions a solution must meet to be acceptable to key stakeholders. This is how technique 10.1 of the BABOK Guide v3 frames them [2].

They are probably the first thing a business analyst learns to write. And for good reason: for the team they are a checklist. Developers build against it. Testers check against it.

We already have a separate article on the technique itself: Acceptance and Evaluation Criteria: BABOK 10.1 for CBAP. This one is about form: how to write criteria so that people actually read them.

Why acceptance criteria formats matter for CBAP and AAC

Both exams rely on guides that describe criteria in different shapes, so you need to tell a rule from a scenario.

CBAP builds on the BABOK Guide v3, where acceptance criteria are technique 10.1 [2]. You can practise CBAP-style questions in our CBAP exam simulator.
AAC builds on the Agile Extension to the BABOK Guide v2. There, Behaviour Driven Development (BDD) is technique 7.2. Its purpose is to increase value and communication by focusing on the intended customer behaviour [3].

The 3C lens: Card, Conversation, Confirmation

The 3C model describes a user story as three parts: the Card, the Conversation and the Confirmation. Ron Jeffries introduced it in an essay on Extreme Programming [1].

Card — a short written token of the requirement.
Conversation — the talk where the details are worked out.
Confirmation — proof that the story is done. In the original text, the customer confirms success through acceptance tests, and examples work best, preferably automated [1].

My reading is a bit wider. Confirmation is the agreement on what the right content of the card is. When the team and the stakeholder shake hands, confirmation is reached. From that moment, everything on the card is the agreed scope: the description, the criteria, the attachments, the links.

A practical consequence follows. A link can be an acceptance criterion. If a card says "Works as in the design" and links to a design file that matches the task, the link already says how the feature should work.

And if the design is a clickable prototype with notes, writing the same behaviour again in the ticket only duplicates it. The team then keeps two places in sync, and sooner or later they drift.

I may be wrong here. The original 3C text ties Confirmation to tests, not to the whole card. If you read 3C differently, write to us at contact@certificate.tips. I would really like to hear how your team sees it.

Acceptance criteria formats compared

There are five common formats, and each one is good at a different job.

Format	Example	Good for	Weak spot
Rule statement	"The user can reschedule a delivery up to 2 hours before the slot."	Business rules, quick checklists	Looks complete but can hide gaps [4]
Given/When/Then scenario (BDD)	"Given a slot tomorrow, when the user picks another, then the order shows it."	Behaviour that business and developers both read; test automation [5, 3]	Long and hard to maintain when misused [6]
Example table	Rows of inputs and expected results, e.g. order time vs. allowed reschedule	Calculations, many combinations [7]	Needs a session to collect good examples
Design or prototype link	"Works as in the design, frame Checkout v3"	UI-heavy work, annotated prototypes	Hard to trace which design element matches which criterion [8]
Use case	Main flow, alternative flows, exceptions	Complex interactions	In my experience hard to read and hard to reproduce

Rule statements. This is the most common form: a sentence about a quality or property of the system. It comes with different openings: "The system can…", "The system shall…", "The user can…". One BDD practitioner describes acceptance criteria as a set of rules, and scenarios as concrete examples of those rules. She also notes that a criterion written as Given/When/Then is still a criterion [4].

Given/When/Then. The format was created so that a story's acceptance criteria could be expressed in a way analysts found natural; its author put it simply: a story's behaviour is its acceptance criteria [5]. In the Agile Extension this sits under BDD [3]. More on the technique: Behavior-Driven Development (BDD).

Rules and scenarios together. A consultant with 15+ years of practice sees newer teams keep a rule list and scenarios side by side, which duplicates the rules. He turns the rules into scenarios and drops the rules [9]. A Cucumber co-founder argues the opposite way round: written rules look complete but hide gaps, so he combines rules and examples through example mapping [7].

Real switch from checklists. A UK government delivery team moved from checklists to plain-English Given/When/Then written at the analysis stage. Checklists gave developers no boundaries and testers no guidance; technical details moved into separate notes [10].

The cost of Gherkin. Not everyone is happy with it. A test automation practitioner who has worked since 2006 argues that the Gherkin parsing layer adds maintenance cost without enough return [11]. The author of a well-known book on specification by example calls Given/When/Then a sharp tool that produces long, unmaintainable tests when misused [6].

Use cases. Use cases are an older form that still lives in our history. My take: they are hard to reproduce and hard to read. You cannot glance at one and quickly see how the feature should work.

Number every acceptance criterion

Write acceptance criteria as a numbered list, not as dashes. Nested items get numbers too.

1. The user can reschedule a delivery from the order page.
   1.1. Rescheduling is available up to 2 hours before the slot starts.
   1.2. The slot list shows only free slots.
2. After rescheduling, the user receives a confirmation e-mail.

The reason is simple. Later you will need to point to a change: "criterion 1.1 changed from 2 hours to 4 hours". With dashes, you can only say "the second bullet from the top", and that breaks the first time someone adds a line.

Some teams go further and keep criteria in a separate Jira field with checkboxes, so each one can be tracked and searched [12]. Numbering does a similar job inside a plain description.

Experts disagree on who writes acceptance criteria

Practitioners agree that criteria must be shared, but not on who writes them and when.

1. The product owner writes them. A long-running agile training company writes conditions of satisfaction on the back of the story card and makes the product owner primarily responsible for them [13]. A Scrum forum participant argues that the party who accepts the work should define the criteria [14].

2. The developers write them. A Scrum.org blog author argues that the people doing the work should write the criteria, not the product owner. Criteria written outside the team invite "this item is not ready" pushback [15].

3. The whole team writes them in refinement. One forum member says his team writes criteria for every item during refinement, as Given/When/Then, so they feed automated tests [14]. Another describes two real teams: one writes Gherkin in refinement, the other writes a few English bullets and holds a Three Amigos session inside the Sprint [16]. Testers run Three Amigos for 5–15 minutes per card; one tester tells how a developer and a tester read the same criterion differently and had to meet again [17].

4. An analyst writes them, the team signs off each line. A software engineer describes a flow where a product owner or BA writes criteria before development, and everyone reviews and agrees each line [18]. A CBAP-certified senior BA with 20+ years of practice warns that analysts focus on requirements and neglect acceptance criteria, so validation falls on QA [19].

What testers check in any of these flows is close: a common understanding, no gaps, testability and, for APIs, concrete examples [20].

The worst format: no acceptance criteria at all

The most common and the worst option is when criteria do not exist in any form. Agreements live in the heads of a few people, for example a developer and a product manager.

I saw this on a data analytics product for a consulting company. When I joined, there was no information about the project at all. The product manager did not see writing requirements as part of the job, so tickets stayed empty. It was the first project where I worked on requirements and built a knowledge base.

It ended with a two-level knowledge base:

An internal knowledge base for the team.
A detailed user guide for users, synced with the internal one.

Versions made this necessary. Each client had its own deployment and could stay behind, skip a release or not update at all. So we had to record which features existed in which version, and users could open the guide for their own version. Our options for configuration were limited. The main message to users was: if your version does not have the feature, we cannot set it up — please update.

So, criteria in someone's head do not survive the first version split. Written, versioned criteria do.

Showing the delta: as-is vs to-be

The most effective approach I have used is also the least common: show each task as a delta of the feature description.

On a social network for Australian students, I built such a system. Feature descriptions lived in Confluence, in any form. Each task linked to a page that showed the difference between the previous and the new version of the description: removed text in red, added text in green. The task showed exactly what had to change, and the feature description stayed the single source of truth.

A BDD author draws the same line: stories record changes and are temporary, while feature files document what the product does now [21]. A Scrum.org author adds that new findings should become new backlog items, not edits to old stories [22].

I still think this is the best way to work with requirements. It removes the problem of keeping the same thing in two places. It is also expensive to maintain, especially without AI.

And it did not take hold. Developers and testers were used to a simpler flow: the task just says what to do. The new way felt unfamiliar. This is status quo bias — a preference for keeping the current state of affairs [23]. So the cost of such a change is not the tool. It is the habit of the people who read the requirements.

Common misconceptions

"Given/When/Then is the agile format." It is one format. A rule written as Given/When/Then is still a rule [4].
"A design link is not a criterion." If the team agreed on the card, the linked design is part of what was confirmed.
"More text makes criteria safer." Rules repeated as scenarios create duplication that drifts [9].
"The analyst writes them alone." Every flow above ends with team agreement, whoever holds the pen [14, 18].

Practice Questions

1. (CBAP) A business analyst needs to define the conditions a single delivered solution must meet so that stakeholders accept it. Which technique fits best?

A. Evaluation criteria B. Acceptance criteria C. Benchmarking D. Decision analysis

Answer: B. Acceptance criteria state what a solution must meet to be acceptable [2]. Evaluation criteria are used to compare and rank several options.

2. (AAC) A team wants examples of customer behaviour that both business people and developers can read, and that can become automated tests. Which Agile Extension technique fits?

A. Story Mapping B. Relative Estimation C. Behaviour Driven Development D. Spikes

Answer: C. BDD focuses on the intended customer behaviour and communication between stakeholders and delivery teams [3].

3. (CBAP / AAC) A team keeps a rule list and Given/When/Then scenarios with the same content in each ticket. They often disagree with each other. What is the best next step?

A. Add a third format to resolve conflicts B. Ask a tester to sync both lists every Sprint C. Keep one source of truth and link to it from the other place D. Freeze the criteria after Sprint Planning

Answer: C. Duplicated representations drift; practitioners remove one of them [9].

Conclusion: the gap between the guides and real acceptance criteria

The guides describe criteria as an agreed basis for acceptance; real teams often reduce them to bullets, or skip them.

Area	Standard	Reality	Delta
Criteria exist	Conditions to be acceptable to stakeholders [2]	Analysts neglect criteria, validation falls on QA [19]	Under-used
Behaviour examples	BDD focuses on intended customer behaviour [3]	Some teams write a few English bullets; some see Gherkin as overhead [16, 11]	Reduced to bullet lists
Confirmation	Customer confirms through acceptance tests [1]	Teams agree in refinement or Three Amigos [14, 17]	Reduced to team agreement
Keeping criteria current	Examples, preferably automated [1]	Stories and living docs drift apart; designs are hard to trace to criteria [21, 8]	Under-used

So the format is a choice. The agreement is not. Number the criteria, keep one source of truth, and treat everything the team confirmed on the card as part of the deal.

FAQ

What are the main acceptance criteria formats?

The common formats are rule statements ("The user can…"), Given/When/Then scenarios, example tables, use cases and links to an agreed design or prototype. Rules suit business rules and checklists; scenarios and examples suit behaviour and test automation.

Is Given/When/Then required in agile teams?

No. Given/When/Then is part of Behaviour Driven Development, which is one technique in the Agile Extension to the BABOK Guide v2. Many teams write plain bullet criteria and agree on them in refinement or a Three Amigos session.

Can a link to a design be an acceptance criterion?

Yes, if the team agreed on it. If an annotated prototype already shows the behaviour, repeating it as text in the ticket creates a second place to maintain. The risk is traceability: it can be hard to see which design element matches which criterion.

Why should acceptance criteria be numbered?

Numbers let you point to a specific criterion when it changes, for example "criterion 1.1 changed from 2 to 4 hours". Dashes break as soon as someone adds or removes a line.

What is the 3C model?

3C describes a user story as Card, Conversation and Confirmation. The card is a short token of the requirement, the conversation works out the details, and the confirmation shows the story is done, usually through acceptance tests.

Sources