mvp-product

Acceptance Criteria: Turning User Stories into Testable Commitments

The conditions a user story or feature must satisfy to be accepted by the product owner, expressed as testable statements.

Acceptance criteria are the conditions a feature must satisfy to be considered complete and accepted by the product owner. They are the bridge between a user story, which describes what a user needs, and the actual implementation, which must meet specific, testable conditions to deliver that need. Without acceptance criteria, the definition of 'done' is subjective and negotiable. A developer can build something that technically satisfies the user story but misses the product owner's intent. With clear acceptance criteria, there is an explicit contract: the feature passes or fails against defined conditions that were agreed before development began. For AI product teams, acceptance criteria have an additional dimension that traditional software teams do not face: they must define what constitutes acceptable AI behaviour, not just functional behaviour. This guide covers how to write effective acceptance criteria, the Given-When-Then format, and how to extend acceptance criteria for AI-specific requirements. In the UK and EU regulatory context, acceptance criteria serve a dual purpose for AI features in regulated sectors. They define functional completeness for the product team and they create testable, auditable documentation of compliance implementation. GDPR obligations such as personal data disclosure, consent mechanisms, and data deletion paths can be expressed as acceptance criteria, making them explicitly testable rather than assumed. FCA consumer duty requirements for clear AI output labelling and EU AI Act transparency obligations both have natural expression as acceptance criteria attached to the relevant user stories. This approach means compliance requirements are built in from the start of development, not retrofitted after a regulatory gap is identified. SpeedMVPs writes AI-specific and compliance-aware acceptance criteria during the discovery sprint for every engagement. Fixed pricing from GBP 8,000, 2-3 week delivery from Hemel Hempstead.

Why Acceptance Criteria Matter

The most common cause of rework in software development is not technical failure but communication failure: the developer built what the story said, not what the product owner meant. Acceptance criteria close this gap by making the intent explicit in testable terms before development begins. They also serve as the basis for quality assurance: a tester can read the acceptance criteria and design test cases without needing to interpret ambiguous requirements. For AI products, they are essential because AI features have failure modes that do not exist in deterministic software. A traditional feature either works or it does not. An AI feature may work in 80% of cases and fail silently in 20%. Without explicit acceptance criteria that define what percentage of cases must work, at what quality level, how edge cases are handled, and what user feedback is provided on failures, there is no objective way to determine whether the feature is complete. Acceptance criteria force these conversations to happen before the feature is built, not after it is shipped.

The Given-When-Then Format

The Given-When-Then (GWT) format, also used in behaviour-driven development (BDD), structures acceptance criteria as scenarios that describe the context, an action, and an expected result. Given describes the starting state or context. When describes the trigger or action the user takes. Then describes the expected outcome. For example: Given a user has uploaded a PDF document to the analysis queue, When the analysis job completes, Then the user is shown a summary of the document's key points with each point linked to the relevant page number. This format makes acceptance criteria testable by design: for every criterion, you can write a test that sets up the Given state, executes the When action, and asserts the Then outcome. It also makes criteria unambiguous: 'the document is analysed correctly' is not an acceptance criterion. 'The user is shown a summary with key points linked to page numbers' is. The GWT format forces precision at the right moment, before development begins.

Writing Acceptance Criteria for AI Features

AI features require acceptance criteria that address output quality, not just functionality. Functional acceptance criteria for an AI classification feature might specify: when the user submits a support ticket, the system returns a predicted category within 2 seconds. Quality acceptance criteria add: the predicted category is correct for at least 85% of test cases in the evaluation dataset. Edge case acceptance criteria add: when the ticket content is ambiguous or insufficient to classify, the system returns an 'unclassified' category rather than a low-confidence prediction. Failure handling criteria add: when the AI service is unavailable, the system queues the ticket for manual review and notifies the user that classification will be delayed. Each of these criteria addresses a different dimension of AI feature completeness: speed, accuracy, robustness, and resilience. Without all four dimensions addressed in the acceptance criteria, a sprint can close with an AI feature that is technically complete but not actually ready for production use.

INVEST: Criteria for Good Acceptance Criteria

Just as user stories can be evaluated against the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable), acceptance criteria can be evaluated against their own quality attributes. Good acceptance criteria are specific: they describe a concrete, observable outcome rather than a vague quality. They are testable: there is a clear method for determining whether the criterion is met. They are non-redundant: each criterion adds a distinct condition not already covered by another. They are complete: together the criteria cover the most important dimensions of the feature's expected behaviour. And they are agreed: the product owner, developer, and tester all understand and accept the criteria before development begins. Common failures in acceptance criteria writing include criteria that are too vague to test (the AI response should be helpful), criteria that specify implementation rather than behaviour (the system should use GPT-4o to classify the ticket), and criteria that omit the most common edge cases because they were not thought of during story writing.

Acceptance Criteria and Compliance Requirements

For UK and EU products in regulated sectors, acceptance criteria serve a dual purpose: they define functional completeness and they document compliance implementation. GDPR compliance for an AI feature can be partially expressed through acceptance criteria. For a feature that processes personal data, relevant criteria might include: the system does not store personal data from user inputs beyond the session, the user is shown a clear disclosure that their input is processed by an AI system, and the user can request deletion of all stored personal information through the account settings. FCA consumer duty requirements for AI-generated financial information can be expressed as acceptance criteria: all AI-generated content that could be interpreted as financial advice is accompanied by a regulatory disclaimer. ICO guidance on AI transparency can be operationalised as: users interacting with an AI chatbot are informed at the start of the session that they are interacting with an AI system. Expressing compliance requirements as acceptance criteria makes them testable and auditable, which supports both internal compliance management and external regulatory review.

Acceptance Criteria at SpeedMVPs

At SpeedMVPs, acceptance criteria are defined during the discovery sprint for every engagement, before a line of code is written. For AI features, we include quality thresholds measured against representative evaluation datasets, edge case handling specifications, and error feedback requirements alongside functional behaviour criteria. The acceptance criteria document is the primary scope contract for the engagement: if it is in the criteria, it is in scope. If it is not, it is not. This discipline protects delivery timelines and prevents the scope drift that is the most common cause of AI MVP delays. Acceptance criteria are included in the delivery documentation so clients have a complete, testable record of what was committed to and what was built. Projects from GBP 8,000, 2-3 week delivery, full code and documentation ownership on completion.

Frequently Asked Questions

How many acceptance criteria should a user story have?+

Between three and eight, typically. Fewer than three often means the story is underspecified and important edge cases have been omitted. More than eight often means the story is too large and should be split. A story with ten acceptance criteria can usually be decomposed into two stories of five criteria each, which are simpler to implement, test, and accept independently. For AI features, the typical range is four to seven, covering the happy path, at least one edge case, a failure mode, and a quality threshold.

Who is responsible for writing acceptance criteria?+

The product owner typically writes the initial acceptance criteria, because they are closest to the user needs and business requirements. The development team refines them to add technical precision and identify missing edge cases. QA or the tester reviews them to ensure they are testable and complete. The three-amigos practice, a conversation between product owner, developer, and tester before development begins, is one of the most effective ways to catch acceptance criteria gaps before they become rework after development is complete.

What is the difference between acceptance criteria and test cases?+

Acceptance criteria describe the conditions the feature must satisfy. Test cases describe the specific scenarios that verify those conditions are met. A single acceptance criterion may require multiple test cases to verify fully: the happy path, boundary cases, and negative cases. Acceptance criteria belong in the product backlog alongside the user story. Test cases belong in the QA plan or test management system and are derived from acceptance criteria during the testing phase.

How do you handle acceptance criteria for non-functional requirements like performance?+

Non-functional requirements like performance, availability, and security make excellent acceptance criteria and should be included in the relevant user story rather than left as implicit assumptions. For an AI feature: 'When the user submits a query, the AI response begins streaming within 3 seconds for 95% of requests under normal load conditions'. For a data processing feature: 'The batch job completes processing of 10,000 records within 30 minutes'. Quantified non-functional criteria are testable and prevent the common situation where performance requirements are discovered in production after launch.

What happens if a feature fails acceptance criteria after development is complete?+

The feature is not accepted. It returns to development for remediation against the specific failing criteria. This is a normal and healthy part of agile development: the sprint review is when work is formally accepted or rejected. The acceptance criteria that were agreed at story writing time are the benchmark. If the criteria were poorly written and the developer built something that technically satisfies the criteria but not the intent, that is a documentation quality issue to address in the retrospective. The criteria themselves, not intent or interpretation, are the contract.

SpeedMVPs writes acceptance criteria as part of every discovery and delivery engagement, ensuring AI features are built to a defined quality standard from day one. From GBP 8,000, 2-3 week delivery. Get a free consultation at speedmvps.co.uk

Get a Free Quote