7 Agile Acceptance Criteria Examples That Clarify Testing

Agile acceptance criteria define the exact conditions that a user story must satisfy to be considered complete, functional, and ready for production deployment. By establishing explicit boundaries, expected behaviors, and error states before development begins, well-crafted acceptance criteria eliminate guesswork for quality assurance (QA) engineers, streamline automated test creation, and ensure aligned implementation across cross-functional software teams.

The Vital Role of Acceptance Criteria in Software Quality

In Agile frameworks such as Scrum and Kanban, a user story describes a piece of functionality from the perspective of an end user. However, user stories alone are intentionally high-level. Without explicit acceptance criteria (AC), software developers and test engineers are left to interpret business intent independently, frequently leading to mismatched expectations, scope creep, and untested edge cases.

Acceptance criteria serve as the explicit contract between the Product Owner, software developers, and QA testers—a triad often referred to as the "Three Amigos." When written effectively, acceptance criteria transform abstract requirements into testable assertions. They outline precisely what functionality must exist, how the system should handle invalid inputs, and what performance or security constraints apply.

From a testing perspective, high-quality acceptance criteria simplify test design. Quality assurance engineers can directly translate acceptance criteria into manual test scenarios, boundary value tests, and automated Behavior-Driven Development (BDD) test suites using tools like Cucumber or SpecFlow. By shifting testing conversations to the refinement stage—well before code is written—teams prevent defect creation rather than merely detecting bugs after development.

According to guidance from the Agile Alliance, defining clear criteria for completion at the story level reduces rework and establishes shared accountability across technical and non-technical team members.

Formats for Writing Clear Acceptance Criteria

Agile teams primarily utilize two formats to document acceptance criteria: scenario-based (Behavior-Driven Development) and rule-based (checklist style). Selecting the right format depends on the nature of the feature being built.

1. Scenario-Based Format (Given-When-Then)

Popularized by Behavior-Driven Development, the Given-When-Then format structures criteria around user interactions and system states:

• Given: The initial context or pre-condition of the system before an action takes place.
• When: The specific action, event, or trigger performed by the user or system.
• Then: The expected, observable outcome or post-condition resulting from the action.

This format excels at defining workflow sequences, interactive user interfaces, and state transitions because it directly mirrors how automated test scripts execute.

2. Rule-Based Format (Checklist)

The rule-based format lists specific conditions, system constraints, business logic rules, and non-functional bounds using bulleted requirements. This format is ideal for backend APIs, security restrictions, database schema validations, and complex business calculations where sequential user scenarios are less applicable.

7 Agile Acceptance Criteria Examples That Clarify Testing

The following seven examples illustrate how to structure acceptance criteria across common software engineering scenarios. Each example includes the user story context, formatted criteria, and a detailed explanation of how the criteria simplify test case creation for QA teams.

Example 1: User Authentication & Multi-Factor Login

User Story

As a registered user, I want to log in using multi-factor authentication so that my account remain secure against unauthorized access.

Acceptance Criteria (Scenario-Based / BDD)

Scenario 1: Successful login with valid credentials and OTP

• Given an active user is on the login page with multi-factor authentication (MFA) enabled,
• When they enter a valid email address and password, and submit the form,
• Then the system redirects them to an OTP verification page and sends a 6-digit code via SMS.
• And when they enter the correct 6-digit code within 5 minutes, they are successfully redirected to their dashboard.

Scenario 2: Expired OTP handling

• Given the user is on the OTP verification page,
• When they enter the 6-digit code after 5 minutes have elapsed,
• Then the system displays the error message: "Your verification code has expired. Please request a new code."
• And the submit button remains disabled until a new code is requested.

How It Clarifies Testing

This criteria design outlines clear state transitions and time-based parameters. Instead of testing vague success states, QA engineers immediately identify four explicit test cases:

1. Happy-path verification with valid credentials and prompt OTP submission.
2. Negative testing with an expired verification code (testing the 300-second boundary).
3. UI validation for button state suppression upon code expiration.
4. Integration testing for SMS gateway delivery triggers.

Example 2: E-Commerce Payment Gateway Integration

User Story

As an online shopper, I want to pay for my shopping cart using a credit card so that I can complete my order securely.

Acceptance Criteria (Rule-Based / Checklist)

• Accepted Payment Methods: System must validate Visa, Mastercard, and American Express card numbers via Luhn algorithm validation prior to payment submission.
• Form Field Validations:
  • Card Number: Must accept 15 to 16 numeric digits; formatted with spaces every 4 digits.
  • Expiration Date: Must require MM/YY format; must reject past dates relative to current UTC time.
  • CVV/CVC: Must accept exactly 3 numeric digits for Visa/Mastercard and 4 digits for American Express.
• Error Handling:
  • If payment is declined due to insufficient funds, display: "Transaction declined: Insufficient funds. Please try another card."
  • If the payment gateway times out (>8 seconds), display: "Payment server did not respond. Your card was not charged. Please try again."
• Post-Condition: Upon successful payment processing, the system must generate a unique Order ID, log the payment gateway transaction token, and transition the order status to Processing.

How It Clarifies Testing

Rule-based structures for payments remove ambiguity surrounding third-party API behavior. Testers do not need to guess what constitutes a valid card or how errors should be presented. QA can construct precise equivalence partitions (valid vs. invalid card lengths) and boundary condition tests (current month/year vs. previous month/year). Furthermore, explicit failure states allow testers to mock gateway timeouts and verify retry logic.

Example 3: Self-Service Password Reset Flow

User Story

As a user who forgot my password, I want to reset my credentials via email link so that I can regain access to my account.

Acceptance Criteria (Scenario-Based / BDD)

Scenario 1: Reset link request for existing email

• Given a user is on the "Forgot Password" page,
• When they enter a registered email address and click "Send Reset Link",
• Then the system displays a confirmation message: "If an account exists for this email, a reset link has been sent."
• And an email containing a single-use token link valid for 15 minutes is dispatched.

Scenario 2: Account enumeration prevention for unregistered email

• Given a user is on the "Forgot Password" page,
• When they enter an unregistered email address and click "Send Reset Link",
• Then the system displays the identical confirmation message: "If an account exists for this email, a reset link has been sent."
• And no email is sent, and no error message reveals account non-existence.

How It Clarifies Testing

Security requirements frequently suffer from ambiguous criteria. By specifying identical messaging for both existing and non-existing accounts, these criteria enforce secure user experience guidelines designed to prevent account enumeration attacks, as detailed in security standards maintained by OWASP. QA engineers can immediately author functional test cases for email dispatch while incorporating security test cases that inspect HTTP response codes to ensure no technical leakage occurs.

Example 4: Product Catalog Search and Filtering

User Story

As a retail customer, I want to filter search results by price range and category so that I can quickly find relevant products.

Acceptance Criteria (Hybrid Scenario & Rule-Based)

• Default State: Performing an empty search returns all published products ordered by Relevance with 24 items per page.
• Filter Constraints:
  • Selecting a price range (e.g., $20 - $50) filters results dynamically within 500 milliseconds of selection.
  • Multiple category checkboxes act using logical OR conditions within categories and logical AND conditions across attributes (e.g., Category: Shoes AND Brand: Nike).
• Zero-Results Handling:

  Scenario: No matching products found

  • Given a user applies filters that match zero products,
  • When the search results render,
  • Then display the message: "No products match your selected filters."
  • And provide a single-click button labeled "Clear All Filters".

How It Clarifies Testing

This criteria set combines business logic rules with user interface workflows. It sets an explicit non-functional performance target (500 milliseconds), allowing performance engineers to automate response-time monitoring under load. It also clarifies boolean search logic (AND vs. OR), which prevents developers from coding contradictory backend database queries and gives testers explicit truth tables to validate.

Example 5: Role-Based Access Control (RBAC) Dashboard

User Story

As an enterprise administrator, I want to manage member permissions so that sensitive team metrics remain accessible only to authorized personnel.

Acceptance Criteria (Rule-Based Matrix)

• Unauthorized Direct URL Navigation:
  • If a user with the Viewer role manually navigates to /admin/team-settings, the system must block access, return HTTP 403 Forbidden, and display an unauthorized access alert.

How It Clarifies Testing

Permission systems are prone to security oversights when requirements are vague. Presenting authorization rules in a matrix format provides QA engineers with a complete regression test suite. Testers can systematically perform authorization testing, session privilege escalation checks, and direct object reference tests across all user roles without needing clarification on expected visibility states.

Example 6: Secure Profile File Upload

User Story

As a job applicant, I want to upload my resume to my profile so that recruiters can review my qualifications.

Acceptance Criteria (Scenario-Based with Input Boundaries)

Scenario 1: Uploading a valid document

• Given an applicant is on the document upload interface,
• When they select a file with an extension of .pdf or .docx that is less than or equal to 5 MB in size,
• Then the upload completes, a success message appears, and the file name is listed with a "Delete" option.

Scenario 2: Rejecting unsupported file formats

• Given an applicant is selecting a file,
• When they attempt to upload an unapproved file format (e.g., .png, .exe, .zip),
• Then the client blocks the request before upload begins.
• And displays an inline error: "Invalid file type. Please upload a PDF or DOCX file."

Scenario 3: Rejecting oversized files

• Given an applicant selects a valid .pdf document,
• When the file size exceeds 5.0 MB (e.g., 5.1 MB),
• Then the upload is rejected, displaying the error: "File size exceeds the 5 MB limit."

How It Clarifies Testing

Boundary testing depends heavily on explicit constraints. Defining strict file format types and exact file sizes empowers QA to test exact limit conditions (e.g., 4.99 MB vs. 5.00 MB vs. 5.01 MB). Furthermore, explicit client-side validation rules help automation engineers write targeted UI assertions and API payload validation checks.

Example 7: Third-Party REST API Integration & Handling

User Story

As a developer building an integration, I want our system to query the external shipping service API so that real-time shipping quotes are generated at checkout.

Acceptance Criteria (Technical / API-Focused)

• Endpoint: POST /api/v2/shipping/rates
• Request Schema Validation: Payload must include origin_zip, destination_zip, and weight_oz. Missing fields must trigger HTTP 400 Bad Request with field-level validation messages.
• Success Response: When the external service returns HTTP 200 OK within 2,000 ms, parse the rate_cents value and display the calculated shipping cost to the user.
• Resilience & Failover Rules:
  • If the third-party API returns HTTP 500 Internal Server Error or times out (>2,000 ms), automatically retry the request up to 2 times with exponential backoff (500ms, 1000ms).
  • If all retries fail, fall back to the internal flat-rate shipping calculation rule ($9.99 default) and log a warning event to monitoring services.

How It Clarifies Testing

Technical user stories require acceptance criteria that address backend architecture and failure scenarios. These criteria allow backend QA engineers to build automated integration tests using API testing frameworks. Testers can mock API response codes (200, 400, 500) and simulate network latencies to verify that the retry mechanisms, backoff logic, and fallback pricing calculate accurately without interrupting the user's checkout workflow.

Acceptance Criteria Formats & Testing Applications

The following matrix compares common acceptance criteria formats, highlighting their structures, ideal application areas, and impacts on quality assurance.

Best Practices for Writing Acceptance Criteria That Improve Testability

To maximize the clarity and effectiveness of acceptance criteria, Agile teams should observe several proven engineering practices:

1. Collaborate During Story Refinement (The Three Amigos)

Acceptance criteria should never be written in isolation by the Product Owner. During story refinement meetings, the Product Owner, developer, and QA engineer must review criteria together. The QA engineer brings a critical testing perspective, asking "What happens if..." questions that reveal unstated assumptions before coding starts.

2. Differentiate Acceptance Criteria from the Definition of Done

It is vital to distinguish between story-level Acceptance Criteria and team-level Definition of Done (DoD):

• Acceptance Criteria: Unique to a specific user story. Describes the functional, business, and non-functional requirements for that feature alone.
• Definition of Done: Universal quality standards applied to every story across the codebase (e.g., "Unit test coverage exceeds 80%", "Code reviewed by two peers", "Documentation updated", "Passed security scan").

3. Focus on System Behavior, Not Implementation Details

Acceptance criteria must state what the system should do, not how the software should be coded. Avoid specifying internal class names, database tables, or specific CSS selectors. Overly technical implementation details make criteria brittle and force rewrite cycles whenever internal architecture changes.

4. Include Negative Scenarios and Edge Cases

A common defect pattern occurs when acceptance criteria describe only the "happy path"—the scenario where everything works perfectly. Comprehensive criteria explicitly address invalid inputs, network failures, expired sessions, and missing data, giving QA actionable guidelines for edge-case coverage.

Common Pitfalls That Render Acceptance Criteria Unhelpful

When acceptance criteria are improperly structured, they introduce ambiguity rather than clarity. Teams should watch for these common traps:

• Vague Quality Statements: Criteria containing subjective words like "fast," "user-friendly," or "intuitive" cannot be objectively tested. Replace vague assertions with measurable metrics (e.g., replace "the page must load fast" with "the page must achieve a First Contentful Paint of under 1.5 seconds").
• Overly Broad Scope: If a user story requires dozens of complex acceptance criteria, the story is too large and should be broken down into smaller, independent user stories (following the INVEST framework).
• Unclear Error Messages: Specifying that "an error should occur" leaves developers free to write generic system errors that confuse end users. Always specify exact user-facing error text and system logging behavioral requirements.

Frequently Asked Questions

Who is responsible for writing agile acceptance criteria?

The Product Owner holds primary accountability for ensuring acceptance criteria exist for every user story. However, writing criteria is a collaborative effort. QA testers and software developers review, refine, and add edge-case criteria during backlog refinement sessions to ensure technical feasibility and complete testability.

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

Acceptance criteria define high-level requirements, business boundaries, and expected system outcomes from a functional perspective. Test cases are detailed, step-by-step instructions derived from acceptance criteria that QA testers execute (manually or via automation) to verify that software meets those criteria. One acceptance criterion often generates multiple test cases.

How many acceptance criteria should a single user story have?

Most well-scoped Agile user stories contain between 3 and 6 acceptance criteria. If a story requires more than 8 to 10 criteria, it typically indicates that the story is too complex and should be split into smaller, more focused user stories.

Can acceptance criteria change during an active sprint?

While Agile encourages adaptability, changing acceptance criteria mid-sprint is discouraged once development has commenced because it alters the agreed-upon scope. If essential criteria changes are identified mid-sprint, the team must discuss the impact on sprint goals. Material scope changes may require splitting the story or moving the updated requirements to the backlog for a future sprint.

How do non-functional requirements fit into acceptance criteria?

Story-specific non-functional requirements—such as performance latency thresholds, accessibility standards (e.g., WCAG 2.1 AA compliance), or specific security restrictions—should be explicitly documented within that story's acceptance criteria. Global non-functional requirements, such as overall platform uptime or general architecture rules, belong in the team's overarching Definition of Done or System Requirements specification.

Practical Next Steps for Software Teams

To improve testability and requirements engineering across your development lifecycle:

1. Audit Existing Backlog Items: Review your current user stories in Jira, Azure DevOps, or your tracking system. Identify stories with ambiguous criteria and apply the Given-When-Then format to interactive workflows.
2. Institute "Three Amigos" Sessions: Schedule short, structured 20-minute refinement sessions prior to sprint planning where Product, Development, and QA align on criteria for upcoming features.
3. Automate BDD Scenarios: For scenario-based acceptance criteria, configure automated testing frameworks like Cucumber or SpecFlow to parse acceptance criteria directly into executable automated test suites, establishing true Behavior-Driven Development.