Acceptance Criteria: Turning Business Expectations into Testable Outcomes | Amber Insights #014
Introduction
A requirement can be clearly written and still leave important questions unanswered.
Imagine a Product Owner introduces a user story:
As a registered customer, I want to reset my password so that I can regain access to my account.
At first glance, the intention is straightforward.
The customer has forgotten their password. They need a way to regain access.
But what exactly should happen when they request a reset?
Should the system send an email?
How long should the reset link remain valid?
Can the link be used more than once?
What happens if the email address does not exist?
What happens if the customer requests several reset links?
What should happen when the link expires?
The user story tells us what the customer wants to achieve and why it matters.
It does not necessarily tell us enough to establish whether the solution behaves correctly.
That is where acceptance criteria become essential.
For Quality Engineers, acceptance criteria are more than statements attached to a Jira ticket.
They help turn business expectations into observable, testable conditions.
And when they are written well, they improve communication between Business Analysts, Product Owners, Developers, Quality Engineers and other stakeholders before implementation begins.
01. What Are Acceptance Criteria?
Acceptance criteria are the conditions that a product, feature or user story must satisfy to be accepted by the relevant stakeholders.
They define agreed expectations for the outcome.
A useful way to distinguish them from a user story is:
User story: What does the user want to achieve, and why?
Acceptance criteria: What conditions must be satisfied for that outcome to be considered acceptable?
For example, consider this user story:
As a customer, I want to update my contact telephone number so that the organisation can reach me using my current details.
Possible acceptance criteria include:
The customer must be authenticated before updating their telephone number.
The new telephone number must satisfy the agreed validation rules.
A valid update must be saved successfully.
An invalid telephone number must produce an appropriate validation message.
The updated telephone number must be displayed when the customer returns to their profile.
These conditions give the delivery team a more concrete understanding of the expected behaviour.
However, they should not be treated as a substitute for every business rule, technical specification or quality requirement.
Acceptance criteria provide an agreed basis for acceptance, not necessarily an exhaustive specification of the entire system.
02. Why Acceptance Criteria Matter Before Testing Begins
It is tempting to think of acceptance criteria as something testers use after development.
But their greatest value often begins much earlier.
During refinement, acceptance criteria help teams identify unclear behaviour, missing decisions, and conflicting assumptions.
Imagine a user story says:
As a customer, I want to apply a discount code during checkout.
The team might initially agree that the feature sounds simple.
But several questions emerge:
Can customers apply more than one discount code?
Can a discount code be used after its expiry date?
Does the discount apply to delivery charges?
Can it be combined with existing promotions?
What happens if the order total changes after the discount is applied?
What happens if the code is valid but the customer is ineligible?
Without clarification, different team members may implement or test different interpretations of the same requirement.
Acceptance criteria help make those expectations explicit before they become implementation decisions.
This reduces ambiguity and provides a stronger foundation for development and testing.
03. User Stories and Acceptance Criteria Work Together
A user story and its acceptance criteria serve different but complementary purposes.
USER STORY Describes the user's goal, context, and value. What does the user need, and why? | ACCEPTANCE CRITERIA Describe the conditions for accepting the outcome. How will we know it meets expectations? |
Shared understanding of the expected outcome
Consider an online appointment-booking feature.
User story
As a patient, I want to book an available appointment online so that I can arrange a consultation without contacting the reception team.
Possible acceptance criteria
The patient can view appointment slots available for booking.
The patient can select an eligible appointment slot.
The system must prevent two patients from successfully booking the same slot.
A successful booking must generate a confirmation.
If the selected slot becomes unavailable before confirmation, the patient must receive an appropriate message.
The story describes the value.
The acceptance criteria clarify important conditions for delivering that value.
Notice that the third criterion also reveals a concurrency consideration.
That is an example of why acceptance criteria should be discussed collaboratively rather than written mechanically.
04. What Makes Acceptance Criteria Effective?
Effective acceptance criteria should be sufficiently clear, relevant, and verifiable.
Clear
Different team members should be able to interpret the criterion consistently.
Specific
The criterion should identify the expected behaviour or outcome without relying on vague language.
Testable
There should be a practical way to determine whether the condition has been satisfied.
Relevant
The criterion should support the intended business outcome, applicable rules or identified risks.
Consistent
It should not contradict other acceptance criteria or established business requirements.
Understandable
The language should be accessible to the people who need to review and agree it.
Acceptance criteria do not always need to describe implementation details.
For example, a criterion may specify that a confirmation is generated without prescribing which internal class, service, or database table must perform that operation.
The important distinction is between defining the expected outcome and unnecessarily dictating how the solution must be built.
05. Vague Acceptance Criteria Create Testing Problems
Consider the following acceptance criterion:
The system should display search results quickly.
What does quickly mean?
One second?
Three seconds?
Ten seconds?
Does the expectation apply to all requests?
Does it apply under normal traffic or peak demand?
A stronger criterion might state:
Under the agreed operating load, 95% of product-search requests must return results within two seconds, measured at the defined service boundary.
The numbers here are illustrative; actual targets must be agreed based on business needs and technical context.
Vague criterion “The system should be fast.” | Measurable criterion “95% of requests complete within two seconds under the agreed workload.” |
Illustrative performance target, not a universal standard.
The stronger criterion establishes a measurable expectation.
However, even this statement requires agreement about how the measurement will be performed.
For example, teams may need to define the test environment, workload profile, measurement boundaries, and exclusions.
A measurable statement is only useful when the measurement itself is understood.
06. Writing Acceptance Criteria Using Given, When, and Then
One widely used approach is the Given–When–Then format, associated with Behaviour-Driven Development (BDD).
It structures a scenario around three elements.
Given: The starting context or preconditions.
When: The event or action.
Then: The expected observable outcome.
Consider a password-reset scenario.
Password reset — successful request
Given a customer has a registered account
When the customer submits a password-reset request using their registered email address
Then the system processes the request according to the agreed password-reset policy
And the customer receives the agreed confirmation message
This structure can help teams discuss behaviour in a consistent format.
But it is not a guarantee of good acceptance criteria.
A poorly defined expectation remains poorly defined even when written using Given, When, and Then.
For example:
Then the system should work correctly.
That statement provides little meaningful information.
The format helps structure the conversation.
The quality of the thinking determines the quality of the criterion.
07. Acceptance Criteria Must Consider Failure Behaviour
Teams naturally focus on successful outcomes.
A customer logs in.
A payment succeeds.
An application is submitted.
A report is generated.
But many important requirements become clearer when we ask what should happen if the normal journey cannot be completed.
Consider a payment feature.
A successful payment criterion might state:
When a valid payment is authorised and completed, the customer receives confirmation of the successful transaction.
That is important.
But it does not answer everything.
What happens when the payment provider times out?
What happens if authorisation succeeds but confirmation fails?
What happens if the customer clicks Pay twice?
What happens if the customer loses connectivity during processing?
What happens if the payment is declined?
These questions may lead to additional acceptance criteria, business rules, or technical requirements.
Not every possible failure condition needs to appear directly in the user story.
However, significant failure behaviour should not remain undefined merely because the happy path has been described.
08. Acceptance Criteria Are Not the Same as Test Cases
This distinction is particularly important for new Quality Engineers.
An acceptance criterion describes a condition that must be satisfied.
A test case describes a specific verification activity, usually including the setup, inputs, actions, and expected results.
For example:
Acceptance criterion
An invalid discount code must not reduce the order total.
From that single criterion, a Quality Engineer might design several test cases.
Test scenario | Expected outcome |
Unknown discount code | No discount applied |
Expired discount code | No discount applied |
Ineligible customer | No discount applied |
Code not applicable to selected products | No discount applied |
Previously exhausted code | No discount applied |
The exact scenarios depend on the agreed discount rules.
The important point is that one acceptance criterion can lead to several test cases.
Similarly, a single test case may contribute evidence towards more than one acceptance criterion.
This is why simply counting acceptance criteria and creating the same number of tests is not a reliable measure of coverage.
09. Acceptance Criteria Are Not the Entire Test Scope
This follows naturally from the previous section.
Imagine a story contains five acceptance criteria.
A tester writes five test cases.
All five pass.
Can we conclude that the feature has been comprehensively tested?
Not necessarily.
Testing may also need to consider boundaries, permissions, integration behaviour, data integrity, accessibility, security, regression impact, and relevant non-functional requirements.
Some of those expectations may be captured in acceptance criteria.
Others may be established in broader requirements, standards, policies, architecture documents, or risk assessments.
The purpose of acceptance criteria is to clarify agreed acceptance conditions.
They should not become an artificial boundary that prevents Quality Engineers from exploring relevant risks.
Passing every acceptance criterion is valuable evidence. It is not automatically proof that every important risk has been addressed.
10. Who Should Write Acceptance Criteria?
There is no universal rule requiring one job title to write every acceptance criterion.
In many delivery teams, Product Owners and Business Analysts play a leading role in defining expected business behaviour.
Developers contribute technical understanding.
Quality Engineers contribute perspectives on testability, ambiguity, failure conditions, boundaries, and verification.
Designers, Architects, Security specialists, and other stakeholders may contribute where relevant.
The exact responsibilities depend on the team's delivery model and governance.
What matters is that the acceptance criteria are reviewed and understood by the people responsible for delivering and accepting the feature.
A Quality Engineer should not silently invent a missing business rule and present it as an agreed expectation.
Instead, we should identify the gap, explain its implications, and seek clarification from the appropriate decision-maker.
That is how collaborative refinement strengthens delivery.
11. When Should Acceptance Criteria Be Reviewed?
Ideally, before development begins.
But acceptance criteria may also need review during implementation when new information emerges.
For example, a technical investigation may reveal that an external service behaves differently from what the team expected.
A policy interpretation may change.
A stakeholder may clarify an exception.
A previously unknown dependency may become visible.
When that happens, the team should assess whether the acceptance criteria remain accurate and sufficient.
Changes may affect test scenarios, test data, automation, integration coverage, and previously agreed expectations.
Acceptance criteria should be controlled and traceable, but they should not be treated as permanently frozen when legitimate requirements evolve.
12. A Practical Acceptance Criteria Review Framework
When reviewing acceptance criteria, I find it useful to ask questions across several dimensions.
The Acceptance Criteria Quality Lens
Clarity | Can everyone interpret it consistently? |
Behaviour | Is the expected outcome defined? |
Preconditions | What must already be true? |
Failure | What happens when it goes wrong? |
Boundaries | Which limits and exceptions matter? |
Data | Which data variations affect behaviour? |
Permissions | Who can and cannot perform the action? |
Integration | Which dependencies affect the outcome? |
Verification | How will we demonstrate compliance? |
Traceability | Which requirement or risk does it address? |
This is a thinking framework, not a mandatory checklist for every story. Apply it proportionately to complexity and risk.
The framework helps identify where additional discussion may be needed.
It is particularly useful during backlog refinement, three-way discussions between business, development, testing, and test-design reviews.
13. Common Acceptance Criteria Mistakes
Several patterns can reduce the value of acceptance criteria.
Writing implementation instructions instead of acceptance conditions. A criterion may unnecessarily prescribe internal technical design rather than the expected observable behaviour.
Using vague language. Terms such as fast, easy, secure, or user-friendly can create disagreement unless the expectations are defined.
Ignoring failure conditions. Describing only successful outcomes may leave important business decisions unresolved.
Writing criteria after development is complete. This can turn acceptance criteria into a retrospective description of what was built rather than an agreed basis for delivery.
Confusing acceptance criteria with test steps. Acceptance conditions and detailed execution instructions serve different purposes.
Treating acceptance criteria as exhaustive testing coverage. Passing acceptance criteria does not remove the need for broader risk-based testing.
The objective is not to create the longest possible list.
It is to establish sufficient clarity for the team to deliver and verify the intended outcome.
14. Strong Acceptance Criteria Prevent Defects Before They Exist
Consider a customer-registration story.
During refinement, a Quality Engineer asks:
What happens if the customer submits the registration form twice?
The team realises that duplicate processing has not been considered.
The Product Owner clarifies the expected behaviour.
The Developer designs an appropriate safeguard.
The Quality Engineer prepares relevant scenarios.
The team verifies the agreed outcome.
No defect ticket may ever be raised.
Yet a potentially significant problem has been addressed before release.
This illustrates an important principle.
The value of Quality Engineering is not limited to the defects we discover during execution.
Sometimes it is demonstrated through the ambiguity we resolve, the assumptions we challenge, and the problems we help prevent.
Final Thoughts
Acceptance criteria connect business expectations with delivery and verification.
They help teams move from a general description of what a user needs to a shared understanding of the conditions that make the outcome acceptable.
But good acceptance criteria do not appear automatically.
They require discussion.
They require questions.
They require clarity about business rules, expected behaviour, and relevant exceptions.
And they require an understanding that acceptance criteria, while essential, are only one part of the broader requirements and testing picture.
For Quality Engineers, our contribution is not simply to read acceptance criteria and convert each one into a test case.
It is to examine whether those criteria genuinely describe the conditions needed to evaluate the intended outcome.
Before asking whether a story meets its acceptance criteria, we should first ask:
Are the acceptance criteria clear, complete enough for their purpose, and agreed by the people who understand the business need?
Because when the conditions for acceptance are misunderstood, a team can deliver exactly what it thinks was requested and still fail to meet what the business actually needs.
About the Author
Amber Idumwonyi is a Senior Quality Engineering professional with extensive experience delivering Quality Engineering solutions across UK Government, defence, healthcare, and enterprise technology programmes. She has led Quality Engineering initiatives, developed Test Strategies, contributed to modern testing and automation practices, spoken at industry conferences, and founded LEMP, an organisation focused on practical technology education, mentoring, industry experience, and career development.
Amber is passionate about Quality Engineering, AI-assisted testing, technical leadership, and developing the next generation of technology professionals.
Comments