From Acceptance Criteria to UAT Scenarios: A Business Analyst's Guide

A business analyst can write clear acceptance criteria and still reach UAT with a pack that cannot answer the go-live question. Criteria often describe a successful outcome: a customer receives the correct confirmation, an approver can authorise a request, a price is calculated correctly. They rarely specify the customer type, account state, approval delegation, timing boundary, bad input, or downstream hand-off that makes the outcome meaningful in production.

That distinction matters when someone else is executing the cycle. The BA owns what the business agreed and whether it is ready; a UAT tester needs an unambiguous scenario that preserves that intent without relying on hallway explanations. The test pack is the bridge between requirement and sign-off evidence.

Turn each criterion into an executable business scenario

Start with the criterion, then ask what must be true before the user begins, who performs each action, what data makes the result credible, and what observable outcome proves the requirement. A criterion saying that a sales manager can approve a discount becomes a scenario with a named discount band, customer segment, product, approval threshold, manager role, audit trail, and expected order outcome.

• —Record the requirement or story identifier so the scenario remains traceable when scope changes.
• —State the starting condition, including account status, prior transactions, permissions, effective dates, and required integrations.
• —Use representative data that reflects real values, volumes, currencies, organisations, or customer types rather than a convenient test record.
• —Specify the expected business outcome and the evidence to capture, such as a generated document, status change, ledger entry, notification, or report value.
• —Add a negative or alternate path where invalid input, missing data, a rejected approval, or a downstream failure would create a material business risk.

Prioritise scenarios by consequence, not requirement order

Not every accepted requirement deserves equal UAT effort. Prioritise the scenarios where failure would stop revenue, misstate a financial result, expose restricted data, breach a regulatory control, delay a customer, or leave operations without a safe recovery path. This gives testers a defensible order when SME availability or a release window is constrained.

• —Test end-to-end journeys that cross teams or systems before isolated screen behaviour, because hand-offs hide dependency failures.
• —Give highest priority to payment, pricing, entitlement, payroll, identity, compliance, and customer-facing outcomes with little tolerance for error.
• —Include data boundaries such as period close, effective-date changes, maximum thresholds, duplicate requests, and a user acting on behalf of another person.
• —Identify scenarios dependent on scarce SMEs or scheduled integrations early, then reserve the people and environments required to execute them.
• —Mark lower-risk usability refinements separately from conditions that prevent a business process from completing correctly.

Make the hand-off preserve business intent

A scenario should be executable by a capable tester who was not in the discovery workshop. Avoid instructions such as test discount approval or confirm the workflow works. Describe the actor, business purpose, preconditions, steps, expected result, and evidence in enough detail that a failed result can be discussed against the agreed criterion rather than personal interpretation.

• —Name the business role to use and distinguish it from a system administrator who can accidentally bypass the control being tested.
• —Give the tester a known data set or clear rules for creating one, including any sensitive-data constraints.
• —Define what counts as pass, fail, blocked, and not tested so status reporting cannot conceal uncertainty.
• —Ask testers to capture the actual result, relevant identifiers, timestamps, screenshots or exports, and the point where a journey diverged.
• —Link every logged defect to the scenario and acceptance criterion, with the affected business outcome stated in plain language.

Use defects and evidence to make the sign-off decision

Defect grading is where the BA's requirement knowledge becomes essential. A technically minor defect may block a month-end control; a visible defect may be tolerable if a documented workaround protects the customer and the business. Grade against the criterion, the affected journey, the population exposed, and whether recovery is possible, then confirm the result after a fix rather than accepting a development update as evidence.

“Acceptance criteria define the promise. A well-designed UAT scenario proves that promise for the real people, data, decisions, and exceptions that will meet it after go-live.”