How to Write Acceptance Criteria with Examples (2026 Guide)
A practical guide to writing acceptance criteria that engineers can build against and QA can test. Includes real examples for login, search, payments, and notifications.
TL;DR
Acceptance criteria define when a user story is “done.” The best format is Given/When/Then for scenario-based criteria and checklists for rule-based criteria. This guide covers both formats with real examples, explains common mistakes, and shows how to write criteria that are specific enough to test but not so detailed they constrain implementation.
Two Formats for Acceptance Criteria
There are two common formats. Scenario-based (Given/When/Then) is best for user-facing features where behavior depends on context. Rule-based (checklist) is best for technical requirements, business rules, and constraints. Most stories use scenario-based criteria, with rule-based criteria added for non-functional requirements.
Acceptance Criteria Examples by Feature Type
Login Flow
Given I am on the login page, when I enter valid credentials and click Sign In, then I am redirected to the dashboard and see my name in the header.
Given I enter an incorrect password, when I click Sign In, then I see an error message “Invalid email or password” and the password field is cleared.
Given I have failed 5 login attempts, when I try again, then the account is locked for 15 minutes and I see a lockout message with the remaining time.
Given I check “Remember me,” when I close the browser and reopen it, then I am still signed in for up to 30 days.
Search
Given I type a query in the search bar, when I press Enter, then I see results matching my query, sorted by relevance, within 500ms.
Given my query returns no results, when the results page loads, then I see a “No results found” message with suggestions for alternative queries.
Given I search for a misspelled word, when results load, then I see a “Did you mean...” suggestion with the corrected spelling.
Payment Processing
Given I have items in my cart, when I enter valid payment details and click Pay, then the payment is processed and I see an order confirmation with the order number.
Given my card is declined, when the payment fails, then I see an error message explaining the decline reason and can try a different card.
Rule-based criteria:
- Payment processing must complete within 10 seconds.
- Card numbers must not be stored in the application database.
- All payment API calls must use TLS 1.2 or higher.
Email Notifications
Given a user is mentioned in a comment, when the comment is saved, then the mentioned user receives an email within 5 minutes with the comment text and a link to the item.
Given a user has disabled email notifications, when they are mentioned, then no email is sent but an in-app notification is created.
Given a user is mentioned multiple times in rapid succession, when emails are queued, then mentions are batched into a single email if they occur within 10 minutes.
Common Mistakes
- Writing criteria that are too vague: “The page should load fast.” How fast? “The page should load in under 2 seconds on a 3G connection” is testable.
- Specifying implementation details: “Use a Redis cache for the search index.” Acceptance criteria describe behavior, not implementation.
- Only testing the happy path. Always include error states, edge cases, and boundary conditions in your criteria.
- Writing criteria after development starts. Acceptance criteria should be defined during story writing, before development begins.
How Vantage Makes This Better
Vantage generates tickets with acceptance criteria included. When requirements are extracted from a PRD, Vantage creates tickets that include scenario-based acceptance criteria tailored to each requirement. The criteria are specific to your feature context, not generic templates.
During grooming sessions, Vantage surfaces the product context behind each ticket, so the team can review and refine acceptance criteria with full knowledge of why the feature exists and what success looks like.