How to Choose the Right Acceptance Criteria Format

Choosing the right acceptance criteria format helps product owners, developers, QA testers, and stakeholders agree on what a feature must do before it is accepted as complete.

The two most common formats are:

1. Scenario-based format, often written as Given When Then using Gherkin syntax.
2. Rule-based format, often written as a checklist of conditions.

If you need the full definition first, read our guide on what acceptance criteria are. This guide focuses on formats, templates, and when to use each one.

What is an acceptance criteria format?

An acceptance criteria format is the structure used to describe the conditions a user story, feature, or requirement must meet before it is approved.

A good format should make acceptance criteria:

1. Easy to read
2. Clear enough to test
3. Specific enough to guide development
4. Simple enough for business stakeholders to understand
5. Consistent across the product team

There is no single format that works for every situation. The best choice depends on the feature, the level of detail needed, and how the team plans to test the work.

Format 1: Given When Then Acceptance Criteria Format

The Given When Then format is a scenario-based acceptance criteria format. It describes the starting context, the user action, and the expected result.

It is commonly used in Agile teams, Scrum teams, and behaviour-driven development. It is also closely linked to Gherkin syntax, which gives teams a structured way to write examples that can later support testing.

Given When Then syntax

Use this structure:

Given [the starting context]

When [the user takes an action]

Then [the expected result happens]

Each part has a role:

Given describes the situation before the action happens.

When describes the action or event.

Then describes the expected outcome.

Given When Then example

User story:

As a customer, I want to reset my password so I can regain access to my account.

Acceptance criteria:

Given the user is on the login page

When the user clicks “Forgot password” and enters a registered email

Then the system sends a password reset link to that email

You can also add extra conditions:

1. Given the user receives a password reset link
2. When the user clicks the link after 30 minutes
3. Then the system shows an expired link message

When to use Given When Then

Use Given When Then when the feature depends on user behaviour, system response, or a clear workflow.

It works well for:

1. Login and authentication
2. Checkout flows
3. Booking systems
4. Search and filters
5. Permissions
6. Error states
7. Multi-step user journeys
8. Features that may later need automated tests

To see how these formats work in real software projects, explore our practical acceptance criteria examples, including user stories, forms, APIs, features, and non-functional requirements.

Copy-paste template: Given When Then

User story:

As a [type of user], I want [goal], so that [benefit].

Acceptance criteria:

Scenario 1: [Successful outcome]

Given [starting context]

When [user action]

Then [expected result]

Scenario 2: [Error or edge case]

Given [starting context]

When [user action or invalid condition]

Then [expected error message, restriction, or fallback]

Format 2: Rule-Based Acceptance Criteria Format

The rule-based format lists acceptance criteria as clear conditions or checks. It is often easier to use when the feature does not need a full scenario.

This format is sometimes called checklist acceptance criteria.

Rule-based syntax

Use short, testable statements:

- The system must [expected behaviour].

- The user can [allowed action].

- The user cannot [restricted action].

- The system shows [message or state] when [condition].

Each rule should be specific enough to pass or fail. Avoid vague statements like “the page should be user-friendly” unless you define what that means.

Rule-based example

Feature: Signup form

Acceptance criteria:

- The user must enter a valid email address.

- The email address must be unique.

- The password must contain at least 8 characters.

- The user must accept the terms before submitting.

- The system shows a success message after account creation.

- The system shows a clear error message when required fields are missing.

When to use rule-based acceptance criteria

Use the checklist format when the feature is mainly about rules, validations, permissions, or simple conditions.

It works well for:

1. Form validation
2. Password rules
3. Admin permissions
4. Data fields
5. API response rules
6. Reporting requirements
7. Non-functional requirements
8. Compliance checks

Copy-paste template: Rule-based checklist

Feature or user story:

[Briefly describe the feature or story]

Acceptance criteria:

- [Required condition 1]

- [Required condition 2]

- [Validation rule]

- [Permission rule]

- [Error state]

- [Success state]

- [Edge case]

Image source: Pinterest

Types of acceptance criteria

There are different types of acceptance criteria depending on what the team needs to confirm.

1. Functional acceptance criteria define what the system should do. For example, “The user can download an invoice as a PDF.”

2. Non-functional acceptance criteria define quality expectations such as performance, security, accessibility, or availability. For example, “The dashboard must load within 3 seconds for up to 1,000 records.”

3. Business rule acceptance criteria define rules the system must follow. For example, “Users cannot apply a discount code after payment is completed.”

4. Negative scenario acceptance criteria define what should happen when something goes wrong. For example, “The system shows an error if the uploaded file is larger than 10MB.”

A strong user story often includes more than one type, especially when the feature affects customers, payments, permissions, or sensitive data.

Gherkin Syntax for Acceptance Criteria

Gherkin syntax is a structured way to write behaviour-focused scenarios. In acceptance criteria, it helps teams describe software behaviour in plain language.

A basic Gherkin-style structure looks like this:

Feature: Password reset

Scenario: User requests a password reset link

Given the user is on the login page

When the user submits a registered email address

Then the system sends a password reset link

You can also use And or But to add more detail:

Given the user is on the payment page

And the cart contains one item

When the user submits valid card details

Then the payment is processed

And the user receives a receipt

Keep Gherkin acceptance criteria focused on the expected behaviour. Avoid turning every small technical task into a scenario.

Given When Then vs Checklist format

Use Given When Then when you need to describe a behaviour, journey, or user action.

Use checklist format when you need to define rules, validations, fields, permissions, or quality conditions.

In many real projects, the best approach is to combine both. A payment feature may need Given When Then scenarios for successful and failed payments, plus checklist rules for validation, receipts, permissions, and duplicate payment prevention.

Best practices for choosing an acceptance criteria format

Choose the format that makes the requirement easiest to understand and test.

Before development starts, check that your acceptance criteria are:

1. Written in plain language
2. Specific and testable
3. Focused on outcomes, not implementation details
4. Clear about success and failure states
5. Reviewed by product, development, and QA
6. Small enough to fit the user story or feature scope

If the criteria become too long, the user story may need to be split.

Need help turning requirements into build-ready software?

Clear acceptance criteria are only one part of successful software delivery. Before development starts, your team also needs the right product scope, user stories, technical priorities, and delivery plan.

At Wazobia Technologies, we help startups and businesses turn business ideas, workflows, and requirements into custom software that is clear, testable, and ready to build.

If you are planning a new platform, internal system, SaaS product, or automation project, explore our software development partnership to see how we can support your team from discovery to delivery.

Conclusion

The right acceptance criteria format helps software teams build with less confusion and test with more confidence. Given When Then is best for behaviour and workflows. Rule-based checklists are best for rules, validations, and conditions.

For startups and businesses, clear acceptance criteria reduce rework, improve delivery quality, and help stakeholders approve software with confidence.

For a broader overview, start with our guide on what acceptance criteria are. For real-world scenarios, explore these practical acceptance criteria examples.

FAQ

1. What is the best format for acceptance criteria?

The best format depends on the feature. Given When Then is best for workflows and user behaviour. Checklist format is best for rules, validations, fields, permissions, and simple conditions.

2. What is Given When Then in acceptance criteria?

Given When Then is a scenario-based format. “Given” explains the starting context, “When” explains the user action, and “Then” explains the expected result.

3. Is Gherkin the same as acceptance criteria?

No. Gherkin is a structured syntax used to write behaviour scenarios. Acceptance criteria are the conditions a feature must meet. Gherkin is one way to write those conditions clearly.

4. Can acceptance criteria be written as a checklist?

Yes. Checklist format is common and useful when acceptance criteria describe rules, validations, permissions, non-functional requirements, or simple conditions that do not need a full scenario.