Acceptance Criteria That Actually Work: How to Write Them Before UAT Finds Out You Didn’t

The story was approved. The build matches the criteria. UAT still finds a gap.

The employee can submit a leave request. The manager can approve or reject it. Both criteria pass. The build delivers exactly that. And then a business user in UAT asks: what happens if the dates overlap with an existing approved request? Can a manager approve their own leave? What does the employee see when the request is rejected?

Nobody wrote those down. So the system made a decision, or did not, and UAT is now the first place anyone is checking whether that decision was the right one.

That is not a build problem. The acceptance criteria were too shallow to surface the ambiguity. They confirmed the feature existed. They did not describe how it was supposed to behave.

5-Minute Learning summary

Technique:
Writing acceptance criteria that describe business behaviour, not just feature existence.

Helps with:
Requirements that feel approved but leave “done” undefined, surfaced in UAT instead of refinement.

BA move:
Before refinement closes, write criteria that name the condition, the actor, and what happens when the normal flow fails, then check them against a realistic scenario.

What acceptance criteria are actually for

Acceptance criteria make expected business behaviour explicit. Not just that a feature exists, but how it behaves under real conditions: who can do it, in which state, with what inputs, and what happens when something goes wrong.

Done well, they give delivery and QA something they can actually test. They surface questions while the cost of answering them is still low. And they create a shared reference that keeps business, delivery, and testing aligned on what the requirement actually means.

The short version: acceptance criteria move ambiguity out of UAT and into refinement, where it belongs.

Why most criteria miss the mark

Most acceptance criteria confirm the happy path. The user can submit. The manager can approve. The form saves. The record updates.

These are not wrong. They are just incomplete.

They do not name who can do this and under what conditions. They do not say what happens when required information is missing, or when the user is in the wrong role, or when the system encounters a case that is not the standard one. They describe the feature. They do not describe the behaviour.

The result is that “done” passes internally and business users arrive in UAT testing against a completely different mental model. Not because anyone was careless. Because the criteria never made the behaviour explicit enough for everyone to be working from the same picture.

If your project is dealing with requirements that are too vague to test Your IT Project Requirements Are Too Vague, weak acceptance criteria are often part of the same problem: upstream ambiguity that was never resolved.

What good acceptance criteria actually contain

Good acceptance criteria describe expected business behaviour in a specific, testable way. For any meaningful criterion, ask whether it names:

• the condition or trigger: when does this apply, and under what circumstances?
• the actor or role, where it matters: who is doing this, and does their role change the outcome?
• the expected result: what should happen, in terms a business user would recognise?
• the exception or failure path: what happens when the normal flow does not apply?

Given/When/Then is one useful format for writing criteria this way. It forces specificity: Given a particular context, When a particular action occurs, Then a particular result follows. It works well for teams that find the structure helpful.

The format is not the point. Criteria written in plain sentences that name the condition, the actor, and the expected result do the same job. What matters is the content, not the syntax.

A tangible example: the leave request workflow

This is where the difference becomes visible.

A leave request workflow: employees submit requests, managers approve or reject them. Here is what the acceptance criteria often look like:

• The employee can submit a leave request.
• The manager can approve or reject a leave request.

Both statements are true. Both pass technical review. Neither tells you how the system should behave in the situations business users will actually encounter.

Here is the same requirement with criteria that describe business behaviour:

• An employee with Active status can submit a leave request with a start date, end date, and leave type selected.
• If the selected dates overlap with an existing approved request, submission is blocked and the conflicting dates are shown to the employee.
• On successful submission, the employee sees a confirmation message and the request appears in the assigned manager’s approval queue.
• A manager cannot approve their own leave request. If the approver and requester are the same person, the request routes to the manager’s manager.
• On rejection, the employee receives a notification that includes the reason. The employee can amend and resubmit the request.

Five criteria instead of two. And UAT is less likely to find that the system silently approved a manager’s own leave request, or blocked a submission without telling the employee why, or sent no notification when a request was rejected.

The weak criteria confirm the buttons exist. The stronger criteria describe how the system behaves in the moments that matter to the people using it.

Weak criteria	Stronger criteria
Confirm the feature exists	Describe how the feature behaves
Cover the happy path	Cover conditions, roles, and exceptions
Pass internal review	Give UAT something real to test against
Quick to write and approve	Take more effort at refinement, cost less at testing

How a BA applies this in practice

1. Write criteria before refinement closes, not after the sprint starts. If you cannot write meaningful criteria yet, the requirement is not ready to build.
2. For each criterion, check that it names the condition, the actor where relevant, and the expected outcome — including what happens when the normal flow fails.
3. Walk one realistic scenario from trigger to outcome. If you have to guess at any point, that is a missing criterion.
4. Look for missing branches. What happens when required information is absent? When the user is in the wrong role or status? When the standard flow does not apply?
5. Hand the criteria to QA as the starting point for test scenarios; a direct input, not a separate documentation exercise.
6. Revisit the criteria if scope or business rules change. Outdated criteria create the same problem as weak ones.

The IT Project Problem Diagnostic Checklist includes a Requirements Health section: Use it to check whether your acceptance criteria, business rules, and edge cases are clear enough for delivery and testing.

Common mistakes

Writing criteria after the build starts. At that point, gaps cost real money to fix. Criteria written before refinement closes are cheap. Criteria written to explain a finished build are damage control.

Treating “the user can do X” as complete. It confirms the feature. It does not describe the behaviour. Almost every UAT surprise lives in the gap between those two things.

Writing only the happy path. The standard flow is the easy part. The questions that surface in UAT are almost always the conditions, exceptions, and edge cases that never made it into the criteria.

Making criteria so detailed they become a specification. Acceptance criteria are not the full business rules document. If a criterion runs to a paragraph of conditions and sub-clauses, it is probably doing a different job. If the rule is that complex, it may belong in a separate business rules reference.

Confusing acceptance criteria with test cases. Criteria describe expected behaviour. Test cases describe how to verify it. QA can derive test scenarios from good criteria. That is the point. They are not the same job.

When to use this and when to be realistic

Use this approach for any workflow, business rule, or requirement where “done” could reasonably be interpreted in more than one way. If the requirement touches roles, statuses, conditions, or exceptions, the criteria need to name them. If the story is heading into UAT, being able to write meaningful criteria is a reasonable readiness check. If you cannot write them, that is a signal worth acting on before the build starts.

Be realistic about the limits. Better acceptance criteria reduce UAT surprises. They do not eliminate them. Some gaps only emerge when real users encounter a real system for the first time. That is not a failure of the technique. It is the nature of complex systems.

Very simple, low-risk changes may not need detailed criteria. Use judgment.

And criteria are only useful if people read and use them. If the team treats them as a ticket-completion checkbox after the fact, the problem is not how the criteria are written. Start there.

FAQ

Is Given/When/Then required?

No. It is one useful format that forces specificity. Plain language criteria that name the condition, the actor, and the expected result do the same job. Use whatever format the team will actually work with.

Who should write the acceptance criteria?

The BA typically leads, but criteria should reflect input from business stakeholders and QA. Criteria written in isolation risk the same problem as no criteria at all: one person’s interpretation, undiscussed. The value is in the conversation they generate, not just the text they produce.

How many criteria should a story have?

As many as the behaviour requires, and no more. Two criteria that cover the real behaviour are better than eight that only cover the happy path. If the list is growing very long, check whether the story needs to be split.

Can acceptance criteria replace test cases?

No. Good criteria are the input to test cases, not a substitute for them. A QA engineer can derive test scenarios from well-written criteria, which is exactly how it should work.

What to do next

Take one story in the current sprint and look at its acceptance criteria. Ask whether they name the condition, the actor where relevant, and what happens when the normal flow fails. If they do not, rewrite one criterion and see whether it surfaces a question worth asking before the build starts.

If the same questions keep appearing in UAT, they were almost certainly answerable during refinement, when UAT keeps surfacing gaps that should have been caught earlier, the criteria are often where to look first.

For a fuller picture of where requirement gaps and UAT risks are already building up, the IT Project Problem Diagnostic Checklist covers Requirements Health, UAT Readiness, and five other project health areas. Worth checking before the next release heads toward testing.