Acceptance Criteria Template
A structured template for writing acceptance criteria in the Given-When-Then format. Covers happy path, edge cases, error handling, and accessibility. Use it to create testable, unambiguous criteria that align PMs, developers, and QA.
Why acceptance criteria matter
Acceptance criteria define the conditions a feature must meet to be considered complete. They are the contract between the product manager and the development team. Without clear criteria, developers make assumptions about edge cases, QA engineers do not know what to test, and PMs discover gaps after the code is written.
The Given-When-Then format is the most widely adopted standard for acceptance criteria. It originated in behavior-driven development (BDD) but has been adopted by agile teams of all types because it forces clarity: you must specify the precondition, the action, and the expected result. This template provides the structure and categories you need to write thorough criteria for any user story.
The acceptance criteria template
Five categories of acceptance criteria that ensure thorough coverage of any user story.
The Given-When-Then Structure
Every acceptance criterion follows a three-part structure. "Given" sets the precondition or context. "When" describes the user action or system event. "Then" defines the expected outcome. This format forces clarity because you cannot write a complete criterion without specifying all three parts.
Format: Given [precondition], when [action], then [expected result]. Example: Given I am logged in and on the candidate list page, when I select "5+ years" from the experience filter dropdown, then the list updates within 2 seconds to show only candidates with 5 or more years of experience, and the result count in the header updates to reflect the filtered total.
Tips
- Start the "Given" clause with the user's current state, not the system's internal state
- The "When" clause should be a single action, not a sequence of actions
- The "Then" clause should be objectively verifiable — no subjective language
- If the "Then" clause uses "and" more than once, consider splitting into two criteria
Happy Path Criteria
Happy path criteria describe the expected behavior when everything works correctly. These are the scenarios the developer implements first and the QA engineer tests first. Write 2-3 happy path criteria that cover the primary use case.
Example for a search feature: (1) Given I am on the search page, when I type "project plan" and press Enter, then search results appear within 2 seconds showing documents that contain "project plan" in their title or content. (2) Given search results are displayed, when I click on a result, then I am navigated to that document with the search term highlighted.
Tips
- Cover the most common user flow from start to finish
- Include the expected timing (response within X seconds)
- Specify what the user sees, not what the system does internally
- Test with realistic data volumes (not just 1-2 items)
Edge Case Criteria
Edge cases cover scenarios that fall outside typical usage but must still be handled gracefully. Common edge cases include empty states, maximum inputs, special characters, and concurrent operations.
Example edge cases: (1) Given my search query matches zero documents, when results load, then I see an empty state with the message "No results found for [query]" and suggestions to try different keywords. (2) Given I enter a search query with special characters (&, <, "), when I press Enter, then the search executes correctly without errors and the special characters are displayed properly in the results. (3) Given I submit a new search while the previous search is still loading, when both requests complete, then only the most recent search results are displayed.
Tips
- Always include a "no results" or "empty state" criterion
- Test with special characters, long inputs, and Unicode text
- Consider what happens when the user performs actions quickly (double-click, rapid input)
- Test with minimum and maximum data volumes
Error Handling Criteria
Error criteria define what happens when something goes wrong. Network failures, server errors, permission issues, and validation failures all need explicit criteria. The user should always see a helpful message and a path forward.
Example error criteria: (1) Given the search API returns a 500 error, when the request fails, then I see an error message "Something went wrong. Please try again." with a "Retry" button that re-sends the request. (2) Given my session has expired, when I perform a search, then I am redirected to the login page with a message "Your session has expired. Please sign in again." and after signing in I am returned to the search page.
Tips
- Include at least one network failure criterion for any feature with API calls
- Error messages should be user-friendly, not technical (no stack traces or error codes)
- Always provide a path forward: retry, go back, contact support
- Test what happens when the user's authentication expires mid-action
Accessibility Criteria
Accessibility criteria ensure the feature works for users with disabilities. At minimum, cover keyboard navigation, screen reader compatibility, and visual contrast. These criteria are often overlooked but are required for many organizations and are good practice for all products.
Example accessibility criteria: (1) Given I am using keyboard navigation, when I Tab to the search input and press Enter, then the search executes the same way as clicking the search button. (2) Given I am using a screen reader, when search results load, then the screen reader announces "X results found for [query]" and each result is navigable with arrow keys. (3) Given I have set my system font size to 200%, when I view the search page, then all text and interactive elements remain visible and usable without horizontal scrolling.
Tips
- Test keyboard navigation for all interactive elements
- Ensure screen readers can announce dynamic content changes
- Check color contrast meets WCAG 2.1 AA (4.5:1 ratio for text)
- Test with system font scaling at 150% and 200%
Related templates
Acceptance Criteria Generator
A step-by-step framework for generating criteria from any user story.
View template →Acceptance Criteria Examples
Real-world examples across SaaS, e-commerce, and mobile products.
View template →User Story Template
The standard format with examples and the INVEST quality checklist.
View template →Frequently asked questions
Generate acceptance criteria with AI
Connect your product data and Vantage generates traced criteria from your analytics, designs, and conversations. Free to start.
Free to start. No credit card required.