Acceptance criteria examples: 25 real patterns from production PRDs

Acceptance criteria are the most important and most commonly miswritten section of any PRD. 68% of engineering re-requests trace back to missing or vague acceptance criteria (Scriptonia, 2026). These 25 examples show the difference between criteria that eliminate ambiguity and criteria that create it.

"Good acceptance criteria read like test cases. If a QA engineer can write an automated test from reading your criterion, it's specific enough. If they have to ask a question, it's not."

— Tomas R., QA Lead at a SaaS platform company

The Given/When/Then format: why it works

Given [precondition], When [action], Then [expected result].

This format works because it forces three things: context specificity (Given), action precision (When), and verifiable outcome (Then). Each criterion maps directly to a test case.

Authentication and access control examples

• Given a user has not completed email verification, When they attempt to access the dashboard, Then they are redirected to the email verification screen with a "Resend email" option.
• Given an admin attempts to downgrade a co-admin's role, When they submit the role change, Then the system shows an error: "You cannot change the role of another admin without owner permission."
• Given a session token has been inactive for 30 minutes, When the user attempts any authenticated action, Then the session is invalidated and the user is redirected to the login screen with the message "Your session has expired."

Form validation examples

• Given a required field is left empty, When the user submits the form, Then the field is highlighted in red and the error message "[Field name] is required" appears below it. The form is not submitted.
• Given an email address is entered without an "@" symbol, When the user moves focus away from the field, Then an inline error appears: "Please enter a valid email address."
• Given a password field requires 8+ characters, When the user submits a 7-character password, Then the submission is blocked and the error reads: "Password must be at least 8 characters."

Data export examples

• Given an admin requests a CSV export of team activity, When the export is complete, Then a CSV file downloads with columns: User, Action, Timestamp, IP Address, one row per event.
• Given the export date range spans more than 90 days, When the admin clicks Export, Then the export is blocked with the message: "Export range is limited to 90 days."
• Given no activity exists in the selected date range, When the admin exports, Then a CSV downloads with headers only and a notification: "No activity found for this period."

Notification examples

• Given a user has email notifications enabled for comments, When another user comments on their document, Then an email is sent to the document owner within 2 minutes containing the commenter's name and the first 100 characters of the comment.
• Given a user has turned off all notifications, When any event occurs, Then no email or in-app notification is sent.

Performance and scale examples

• Given a list view contains more than 1,000 rows, When the page loads, Then only the first 50 rows are rendered. Pagination controls allow navigation to subsequent pages.
• Given an API request to /search is made with a query string, When the response time exceeds 2 seconds, Then the response includes a 408 status code and the error: "Request timeout, please try a more specific search."

Error and empty state examples

• Given a user navigates to a URL for a deleted resource, When the page loads, Then a 404 page is shown with the message "This page doesn't exist" and a link to the dashboard.
• Given a user's connected integration returns an auth error, When they view the integration settings page, Then a red "Reconnect required" badge appears next to the integration name.

The 5 acceptance criteria anti-patterns

Anti-pattern	Example	Problem
Too vague	"The feature works as expected"	Cannot be tested
Business language, not system language	"Users should have a great experience"	No testable condition
Ambiguous "should"	"The button should be visible"	Visible to whom? Under what conditions?
Missing precondition	"When user clicks submit, form submits"	Missing: what state is the form in?
Compound criteria	"Field validates AND submits AND redirects"	Three criteria, not one, untestable as a unit