Acceptance criteria are one of the most important things a Business Analyst writes — and one of the most commonly written badly.

When they’re good, they eliminate ambiguity before a developer writes a single line of code. When they’re bad, they cause the most expensive kind of rework: the kind you discover at UAT, when the team has spent three weeks building something that technically meets the requirement but doesn’t actually work the way the business needs it to.

Here’s how to write them properly.

---

What Acceptance Criteria Are (and Aren’t)

Acceptance criteria define what must be true for a piece of work to be considered complete. They answer the question: “How will we know when this is done — and done correctly?”

They are not:

• A test script (though they inform one)
• A requirements document (they’re more specific than that)
• A description of the solution (they describe the outcome, not the implementation)
• Optional (every user story or requirement should have them)

Good acceptance criteria are written before development starts. They’re agreed by the business, the BA, and the development team. They’re testable by the QA team. And they’re specific enough that two different people reading them would reach the same conclusion about whether the work is complete.

---

The Two Main Formats

Given / When / Then (Gherkin format)

This is the most structured approach and the most useful when you need criteria that can be directly turned into automated tests.

The structure:

• Given — the starting state or context
• When — the action or trigger
• Then — the expected outcome

Example:

Given a registered user is on the login page
When they enter a valid email and correct password and click “Log In”
Then they are redirected to their dashboard and a session is created

The format forces you to be specific about context (Given), action (When), and outcome (Then). If you can’t write a clear Then, your requirement isn’t clear enough yet.

Checklist format

A bulleted list of conditions that must be true. Less structured than Gherkin, but often more practical for non-functional requirements or UX-related criteria.

Example for a form validation requirement:

• The email field accepts standard email format only (user@domain.com)
• An inline error message appears if an invalid email is entered: “Please enter a valid email address”
• The form cannot be submitted with an empty required field
• Password must be minimum 8 characters, including at least one number
• The “Submit” button is disabled until all required fields are complete and valid

Use Gherkin when precision matters and automated testing is likely. Use the checklist format when you need to cover multiple conditions quickly, or when the criteria relate to non-functional requirements like performance, accessibility, or security.

---

The Five Rules of Good Acceptance Criteria

1. Testable

Every criterion must be verifiable. If someone can’t clearly demonstrate that a condition is met or not met, it’s not a criterion — it’s a wish.

Bad: “The system should load quickly.”
Good: “The page loads within 2 seconds under normal network conditions (broadband, 50Mbps+).”

2. Clear

Avoid subjective words: “fast,” “easy,” “user-friendly,” “appropriate,” “sufficient.” These mean different things to different people. Replace them with measurable specifics.

Bad: “The interface should be intuitive.”
Good: “A first-time user can complete the registration form without referring to any help documentation.”

3. Scoped to one condition

Each acceptance criterion should state one thing. Compound criteria — ones that test two conditions with “and” — are harder to test and harder to reason about when one condition passes and the other fails.

Bad: “The user can log in and is shown their profile.”
Good: Write two separate criteria — one for successful login, one for profile display.

4. Agreed before development starts

Acceptance criteria only prevent conflict if they’re agreed in advance. Get sign-off from the product owner, a representative business stakeholder, and the technical lead before the story enters a sprint. If there’s disagreement at sign-off, surface it now — not at sprint review.

5. Complete — happy path and edge cases

Most BAs write criteria for the happy path (what happens when everything goes right) and forget the edge cases. Edge cases are where systems fail and where users have the worst experiences.

For every piece of work, ask: what happens when the input is invalid? What happens when a required upstream system is unavailable? What happens when the user does something unexpected? Write criteria for those scenarios too.

---

Common Mistakes

Criteria that describe the solution, not the outcome

Acceptance criteria should describe what the system does for the user, not how the development team should implement it. If your criteria read like technical specifications, push them back up a level.

Bad: “The system calls the PaymentGateway API with a POST request containing the transaction ID and amount.”
Good: “When a user completes checkout with valid payment details, the payment is processed and a confirmation number is displayed.”

Missing the unhappy path

What happens when the payment fails? What happens when a session expires mid-form? What happens when two users try to book the same slot simultaneously? These are the scenarios that cause the most damage in production, and they’re systematically under-documented.

No formal sign-off process

Acceptance criteria that are written but not formally reviewed and approved are just documentation. They won’t prevent the product owner from saying “that’s not what I asked for” at sprint review — because they haven’t committed to them in advance.

Writing them after development starts

Acceptance criteria written after a developer has already made implementation decisions don’t protect the team from rework — they document the work that’s already been done. Write them first. Always.

---

A Quick Template

For each user story or requirement, work through these questions:

1. What is the starting state? (Given)
2. What action triggers the behaviour? (When)
3. What is the expected outcome for the happy path? (Then)
4. What are the edge cases and error states?
5. Are there any non-functional conditions (performance, security, accessibility)?
6. Who needs to sign off before this enters development?

If you can answer all six questions clearly, your acceptance criteria are ready.