{"id":75,"date":"2026-06-26T12:14:00","date_gmt":"2026-06-26T12:14:00","guid":{"rendered":"https:\/\/datadrivenops.co\/blog\/?p=75"},"modified":"2026-06-09T13:03:20","modified_gmt":"2026-06-09T13:03:20","slug":"acceptance-criteria-the-section-most-brds-get-wrong","status":"publish","type":"post","link":"https:\/\/datadrivenops.co\/blog\/acceptance-criteria-the-section-most-brds-get-wrong\/","title":{"rendered":"Acceptance Criteria:The Section Most BRDs\u00a0Get Wrong"},"content":{"rendered":"\n

Of all the sections in a BRD, acceptance criteria is the one that causes the most rework. Not because it\u2019s the most important section \u2014 functional requirements are \u2014 but because it\u2019s the section most teams write last, write quickly, and write vaguely. And then spend the next three weeks in argument about what \u201cdone\u201d actually means.<\/p>\n\n\n\n

I\u2019ve managed a pipeline of 140+ tracked initiatives across seven internal stakeholder groups. The projects that came back for rework \u2014 the ones that hit \u201cdelivered\u201d and then immediately spawned a follow-on ticket for everything the delivery team thought was out of scope \u2014 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.<\/p>\n\n\n\n

This is the fix. It\u2019s not complicated, but it requires a mindset shift: acceptance criteria aren\u2019t a summary of the requirements. They\u2019re 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\u2019t in the room when the BRD was written.<\/p>\n\n\n\n

Why Vague Criteria Are a Structural Problem, Not a Writing Problem<\/h2>\n\n\n\n

When I see acceptance criteria that say things like \u201cthe dashboard should be user-friendly\u201d or \u201cthe report should load quickly\u201d or \u201cdata should be accurate,\u201d the instinct is to flag them as bad writing. But they\u2019re usually a symptom of something deeper: the BRD was written before the team actually agreed on what success looks like.<\/p>\n\n\n\n

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\u2019t in the intake meeting, to understand unambiguously.<\/p>\n\n\n\n

The BRD-to-delivery pipeline I use<\/a> treats the acceptance criteria sign-off as a formal gate \u2014 not a formality at the bottom of a document. If a stakeholder can\u2019t 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.<\/p>\n\n\n\n

\n

\u201cEvery acceptance criterion should pass one test: can someone who wasn\u2019t in the room evaluate it as pass or fail on delivery day? If not, it\u2019s not a criterion \u2014 it\u2019s an aspiration.\u201d<\/p>\n<\/blockquote>\n\n\n\n

The Four Failure Modes<\/h2>\n\n\n\n

Acceptance criteria fail in predictable ways. Recognising the pattern is faster than editing criteria line by line.<\/p>\n\n\n\n

Subjective language.<\/strong> Words like \u201cintuitive,\u201d \u201cclear,\u201d \u201cfast,\u201d \u201cuser-friendly,\u201d and \u201caccurate\u201d are not acceptance criteria. They\u2019re 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.<\/p>\n\n\n\n

\n
Subjective language<\/div>\n
The dashboard should load quickly and display accurate data.<\/div>\n
The dashboard loads within 3 seconds on the standard internal network. Revenue figures match the Salesforce Closed Won total for the same date range within \u00b10.1%.<\/div>\n<\/div>\n\n\n\n

Scope conflation.<\/strong> 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\u2019ll know the behaviour is correct.<\/p>\n\n\n\n

\n
Scope conflation<\/div>\n
The system will automatically assign tickets to the correct queue based on category.<\/div>\n
When a test batch of 50 tickets covering all 8 category types is processed, 47 or more (94%+) are assigned to the correct queue without manual intervention. Assignment logic is documented and reviewable in the admin panel.<\/div>\n<\/div>\n\n\n\n

Missing edge cases.<\/strong> 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 \u201cout of scope\u201d at delivery.<\/p>\n\n\n\n

Untestable states.<\/strong> Criteria that require the reviewer to assess something they can\u2019t observe on delivery day \u2014 future behaviour, performance under load that can\u2019t be simulated in UAT, or integration with systems that aren\u2019t available in the test environment. If you can\u2019t 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.<\/p>\n\n\n\n

The Structure That Works<\/h2>\n\n\n\n

For every functional requirement in the BRD, I write acceptance criteria using a simple three-part structure. It\u2019s not a formal methodology \u2014 it\u2019s just the discipline that prevents the four failure modes above.<\/p>\n\n\n\n

\n
\n
1<\/div>\n
\n
Given \/ When \/ Then<\/div>\n
The classic behavioural format, adapted for ops BRDs. Given<\/em> a specific starting state, when<\/em> a specific action is taken, then<\/em> a specific, measurable outcome occurs. This format forces you to define the starting state (which surfaces missing data assumptions), the trigger (which clarifies scope), and the outcome (which has to be testable). It works equally well for dashboard requirements, process changes, and system integrations.<\/div>\n

<\/p><\/div>\n

<\/p><\/div>\n

\n
2<\/div>\n
\n
Threshold before adjective<\/div>\n
Every qualitative term gets replaced with a number, a percentage, or a defined behaviour. \u201cFast\u201d becomes \u201cunder 3 seconds.\u201d \u201cAccurate\u201d becomes \u201cwithin \u00b10.5% of the source system total.\u201d \u201cComplete\u201d becomes \u201call 12 required fields populated with no nulls.\u201d If you can\u2019t replace the adjective with a number, you haven\u2019t agreed on what success looks like yet \u2014 and that conversation needs to happen before the BRD moves forward.<\/div>\n

<\/p><\/div>\n

<\/p><\/div>\n

\n
3<\/div>\n
\n
One explicit edge case per requirement<\/div>\n
For each functional requirement, identify the most likely edge case and make it explicit in the acceptance criteria. Null values. Empty states. Permission levels. Date range boundaries. Concurrent users. The edge case you write into the criteria is the edge case the developer will test for. The one you leave out is the one that surfaces in UAT and becomes a scope argument.<\/div>\n

<\/p><\/div>\n

<\/p><\/div>\n<\/div>\n\n\n\n

The Sign-Off Test<\/h2>\n\n\n\n

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:<\/p>\n\n\n\n

Can you evaluate this on delivery day without calling me?<\/strong> If the stakeholder needs to ask me what the criterion means when they\u2019re doing UAT, it\u2019s not clear enough. Acceptance criteria should be self-contained.<\/p>\n\n\n\n

Is there any interpretation here that could lead to a disagreement?<\/strong> Read the criterion from the developer\u2019s perspective. Is there a reading of it that technically passes but doesn\u2019t deliver what the stakeholder actually wants? If yes, close the gap before build starts.<\/p>\n\n\n\n

Does this cover the scenario where the data is missing or the edge case fires?<\/strong> The majority of UAT failures I\u2019ve seen aren\u2019t failures of the happy path. They\u2019re failures in boundary conditions that were never written into the criteria.<\/p>\n\n\n\n

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

What Good Acceptance Criteria Actually Look Like<\/h2>\n\n\n\n

Here\u2019s a before-and-after from a real BRD type: an operations dashboard showing ticket resolution metrics by team.<\/p>\n\n\n\n

\n
Dashboard acceptance criteria \u2014 before<\/div>\n
The dashboard should display ticket resolution data accurately. Filters should work correctly. The data should refresh regularly.<\/div>\n<\/div>\n\n\n\n
\n
Dashboard acceptance criteria \u2014 after<\/div>\n
\n 1. Given a user with Operations Manager permissions, when they open the dashboard, ticket counts by team match ConnectWise totals for the same date range within \u00b12 tickets (to account for in-flight tickets at query time).

<\/p>\n

2. When the Team filter is applied, only tickets assigned to the selected team appear. When no team is selected, all tickets appear. When a team with zero tickets is selected, the dashboard displays \u201cNo tickets in this period\u201d rather than an error or blank state.<\/p>\n

3. Dashboard data refreshes automatically every 4 hours. The last-refreshed timestamp is visible on the dashboard. If the refresh fails, a visible alert appears and the previous data remains displayed (does not show blank).\n <\/p><\/div>\n<\/div>\n\n\n\n

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

When Stakeholders Push Back<\/h2>\n\n\n\n

The most common pushback I hear on rigorous acceptance criteria is that it slows down the BRD process. It does. That\u2019s 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 \u2014 back through tech spec, back through development, back through UAT \u2014 is measured in weeks, not hours.<\/p>\n\n\n\n

If a stakeholder can\u2019t define what \u201cdone\u201d looks like in testable terms, that\u2019s a signal that the requirements conversation isn\u2019t finished yet. The acceptance criteria section is doing its job when it surfaces that gap \u2014 not when it glosses over it.<\/p>\n\n\n\n

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 \u201caccepted\u201d means \u201cpassed against written criteria,\u201d not \u201cI looked at it and it seemed okay,\u201d the entire pipeline gets more predictable. That predictability is what allows a shared services team<\/a> to serve multiple business lines without constant scope disputes consuming the delivery calendar.<\/p>\n\n\n\n

\n

Related reading<\/h4>\n