Acceptance Criteria:The Section Most BRDs Get Wrong

Of all the sections in a BRD, acceptance criteria is the one that causes the most rework. Not because it’s the most important section — functional requirements are — but because it’s the section most teams write last, write quickly, and write vaguely. And then spend the next three weeks in argument about what “done” actually means.

I’ve managed a pipeline of 140+ tracked initiatives across seven internal stakeholder groups. The projects that came back for rework — the ones that hit “delivered” and then immediately spawned a follow-on ticket for everything the delivery team thought was out of scope — almost always had the same problem: acceptance criteria that left too much room for interpretation. Not bad developers. Not even bad requirements. Just criteria that a reasonable person on either side of the delivery handoff could read differently.

This is the fix. It’s not complicated, but it requires a mindset shift: acceptance criteria aren’t a summary of the requirements. They’re a test. Every criterion should be a statement that can be evaluated as pass or fail on the day of delivery, by someone who wasn’t in the room when the BRD was written.

Why Vague Criteria Are a Structural Problem, Not a Writing Problem

When I see acceptance criteria that say things like “the dashboard should be user-friendly” or “the report should load quickly” or “data should be accurate,” the instinct is to flag them as bad writing. But they’re usually a symptom of something deeper: the BRD was written before the team actually agreed on what success looks like.

Vague criteria are what happen when the requirements conversation was skipped and the acceptance criteria section got filled in from memory. The stakeholder knows what they want. The writer knows what was discussed. But neither of them has made it explicit enough for a developer who joins the project in week three, or a QA reviewer who wasn’t in the intake meeting, to understand unambiguously.

The BRD-to-delivery pipeline I use treats the acceptance criteria sign-off as a formal gate — not a formality at the bottom of a document. If a stakeholder can’t confirm that each criterion is testable before the BRD moves to tech spec, it goes back for revision. That discipline is the single biggest factor in whether a project comes back for rework.

“Every acceptance criterion should pass one test: can someone who wasn’t in the room evaluate it as pass or fail on delivery day? If not, it’s not a criterion — it’s an aspiration.”

The Four Failure Modes

Acceptance criteria fail in predictable ways. Recognising the pattern is faster than editing criteria line by line.

Subjective language. Words like “intuitive,” “clear,” “fast,” “user-friendly,” and “accurate” are not acceptance criteria. They’re adjectives. They require someone to make a judgment call at delivery, and two people in the same room will make that call differently. Replace every adjective with a threshold, a number, or a behaviour.

Scope conflation. Acceptance criteria that describe what the system does rather than how it will be verified. This is the most common failure mode for technical BRDs. The functional requirement describes the behaviour; the acceptance criterion describes how you’ll know the behaviour is correct.

Missing edge cases. Criteria that describe the happy path only. A dashboard that displays correctly with complete data but breaks when a field is null, or a report that filters correctly for standard users but not for admins, will pass incomplete criteria and fail in production. Good acceptance criteria anticipate the edge case the developer will argue is “out of scope” at delivery.

Untestable states. Criteria that require the reviewer to assess something they can’t observe on delivery day — future behaviour, performance under load that can’t be simulated in UAT, or integration with systems that aren’t available in the test environment. If you can’t test it at delivery, it needs a different mechanism (a post-launch monitoring plan, a separate performance test protocol) or it needs to be removed from the acceptance criteria entirely.

The Structure That Works

For every functional requirement in the BRD, I write acceptance criteria using a simple three-part structure. It’s not a formal methodology — it’s just the discipline that prevents the four failure modes above.

The Sign-Off Test

Before any BRD moves from requirements to tech spec in my pipeline, I run each acceptance criterion through a three-question test with the stakeholder:

Can you evaluate this on delivery day without calling me? If the stakeholder needs to ask me what the criterion means when they’re doing UAT, it’s not clear enough. Acceptance criteria should be self-contained.

Is there any interpretation here that could lead to a disagreement? Read the criterion from the developer’s perspective. Is there a reading of it that technically passes but doesn’t deliver what the stakeholder actually wants? If yes, close the gap before build starts.

Does this cover the scenario where the data is missing or the edge case fires? The majority of UAT failures I’ve seen aren’t failures of the happy path. They’re failures in boundary conditions that were never written into the criteria.

This test adds maybe fifteen minutes to the BRD review meeting. It saves multiple rounds of rework after delivery. The maths are straightforward — which is why requirements management is consistently cited by PMI as one of the top drivers of project success or failure.

What Good Acceptance Criteria Actually Look Like

Here’s a before-and-after from a real BRD type: an operations dashboard showing ticket resolution metrics by team.

The second version took longer to write. It also produced zero UAT arguments, because there was nothing to argue about. Every state was defined.

When Stakeholders Push Back

The most common pushback I hear on rigorous acceptance criteria is that it slows down the BRD process. It does. That’s the point. Time spent making criteria precise before build is a fraction of the time spent resolving disagreements after delivery. The cost of a rework cycle in a BA team — back through tech spec, back through development, back through UAT — is measured in weeks, not hours.

If a stakeholder can’t define what “done” looks like in testable terms, that’s a signal that the requirements conversation isn’t finished yet. The acceptance criteria section is doing its job when it surfaces that gap — not when it glosses over it.

For teams running shared services delivery across multiple internal customers, the acceptance criteria framework also has a second benefit: it creates a shared language for what delivery means. When seven different stakeholder groups all understand that “accepted” means “passed against written criteria,” not “I looked at it and it seemed okay,” the entire pipeline gets more predictable. That predictability is what allows a shared services team to serve multiple business lines without constant scope disputes consuming the delivery calendar.