Acceptance Criteria Examples: Clear Definitions, Formats, and Use Cases

Why this guide matters (and what you’ll get)

If you write, review, or accept work in product development, you already know ambiguous requirements cost time, budget, and morale. This guide gives you practical acceptance criteria examples, clear formats you can copy, and usable rules so you and your team ship predictable results. You’ll get templates, common pitfalls, metrics to measure quality, and quick-win scripts to use in sprint planning or review.

What are acceptance criteria — the short definition you can use today

Acceptance criteria are explicit, testable statements describing how a product or feature must behave for stakeholders to consider it “done.” Think of them as a contract between the requester (product owner, stakeholder) and the team that builds it. They remove ambiguity and make success measurable: either the criteria pass, or they don’t.

Why precise acceptance criteria matter (numbers and impact)

Ambiguous requirements lead to rework. Industry studies and team retrospectives commonly report 20–40% of sprint time can be wasted on clarifying scope or fixing misaligned features. Good acceptance criteria reduce this waste by specifying success in advance, which typically lowers defect counts by 30–50% on targeted stories and shortens review cycles.

Core properties of effective acceptance criteria

Clear — written in plain language your whole team understands.
Testable — a QA engineer (or an automated test) can verify them without interpretation.
Measurable — include exact values, thresholds, or examples.
Focused — each criterion covers a single behavior or acceptance condition.
Non-prescriptive — describe what must happen, not how developers must implement it.

Three common formats for acceptance criteria (and when to use each)

You’ll usually pick one of these formats depending on your context. Each has trade-offs between precision and speed.

1) Given–When–Then (Gherkin-style) — best for behavior-driven workflows

Use Gherkin when you want explicit preconditions, an action, and an expected outcome. It’s ideal for cross-functional teams and automated acceptance tests.

Given: setup or context
When: the action the user or system performs
Then: the expected result

Example (login feature): Given the user has an account with email “[email protected]” and password “CorrectPassword123”, When the user submits those credentials on the login form, Then they are redirected to their dashboard and see their name in the top-right corner within 2 seconds.

2) Checklist-style — best for fast stories and UI changes

Checklist criteria are short, direct items you can tick off during reviews. Use it when behavior is straightforward and you need speed over formal test automation.

Button A displays on desktop and mobile
On click, Button A opens modal B centered on screen
Modal B closes when user clicks outside or presses Esc

3) Rule-based / Acceptance rules — best for data-heavy or edge-case scenarios

When logic has multiple branches or business rules, write rules with examples and prioritized order. This avoids hidden assumptions.

Rule 1: If order total ≥ $100, apply free shipping
Rule 2: If coupon code EXPIREDFREE used, reject with code 410
Example: order $120 with expired coupon → response: shipping charged, coupon rejected

Templates: copy-paste acceptance criteria examples you can use now

Below are practical templates separated by format. Replace the placeholders and tweak specifics for your project.

Gherkin template (web feature)

Given [precondition], When [action], Then [observable result within X seconds].

Given a logged-in user with role “editor”, When they click “Publish”, Then the article status changes to “Published” and a notification email is queued within 30 seconds.

Checklist template (UI change)

Header displays company logo at 120x40px on desktop and scales to 90x30px on mobile
Search input retains focus after pressing “/” shortcut
Keyboard users can navigate the menu using Tab and Arrow keys

Rule-based template (billing logic)

List rules in priority order and include representative examples.

Rule A: If invoice is overdue >30 days, block service access and flag account for collections
Rule B: If partial payment received within 7 days, unblock service but keep collections flag until balance is cleared
Example: Account X overdue 45 days → service blocked, collections flag set, user sees “Payment required” banner

Acceptance criteria examples by domain (realistic samples)

Different types of work need different detail levels. Below are domain-specific acceptance criteria examples to copy and adapt.

Web feature (shopping cart)

When a user adds an item, the cart count increments immediately and persists after page reload.
Applying a 10% discount coupon reduces subtotal and tax is recalculated; total equals subtotal + tax – discount with rounding to 2 decimals.
Guest checkout requires email validation; confirmation email sent within 5 minutes.

API endpoint (orders service)

Use JSON schema and HTTP behavior in acceptance criteria to make tests unambiguous.

POST /orders with valid payload returns 201 and body contains orderId (uuid v4), status “created”, and createdAt ISO8601 timestamp.
If required field userId is missing, return 400 with error code “missing_user_id” and schema {error: string, code: string}.
Processing an order triggers two downstream events: inventory_reserved and payment_initiated within 10 seconds (observed via event log).

Mobile UX (onboarding)

On first open, onboarding screens appear in order and skip option is visible on screen 2 and 3.
Accessibility: VoiceOver/TalkBack reads each onboarding screen title and “Skip” control.
If user completes onboarding, they land on the dashboard and onboarding flag in local storage is set to true.

Measuring “done”: acceptance criteria that include metrics

Adding measurable targets removes guesswork. Use time thresholds, error rates, and percentages where relevant.

Performance: Page loads in under 1.5s on 3G simulated network for 90% of requests.
Error tolerance: API returns 200 for 99.9% of valid requests in load test with 500 RPS.
UX metric: Task completion rate ≥ 95% for a sample of 20 users in quick usability test.

Common pitfalls and how to avoid them (practical fixes)

Teams often write acceptance criteria that are vague, conflicting, or too technical. Below are the five most common problems and immediate remedies.

Vague language: Replace “fast” or “intuitive” with measurable targets (e.g., “loads under 1.5s” or “user completes task in ≤ 2 minutes”).
Multiple behaviors in one criterion: Split into single-responsibility acceptance items so tests and ownership are clear.
Hidden assumptions: Add explicit preconditions (e.g., “Given the user has role X and feature flag Y is enabled”).
Overly prescriptive implementation: Describe expected behavior, not the internal mechanism (avoid “must use library Z”).
Missing edge cases: Include at least two edge-case examples (null, max-length, unauthorized) for each feature.

How to write acceptance criteria in five practical steps

This short process turns fuzzy stories into verifiable outcomes. It fits a 15-minute story refinement slot.

Step 1: Clarify the stakeholder goal — ask “why does this matter?” and write one-sentence objective.
Step 2: Choose a format (Gherkin, checklist, or rules) based on complexity and automation goals.
Step 3: Draft measurable criteria including at least one positive and one negative test (happy path and error case).
Step 4: Review with QA and a developer to confirm testability and remove implementation language.
Step 5: Add acceptance tests (manual or automated) that map 1:1 to criteria and run them during CI or review.

Quick examples of poor vs. good acceptance criteria (and why)

Short comparative examples help you rewrite on the fly during grooming sessions.

Poor: “The search should work quickly.” Good: “Search returns results within 1.2s for 95% of queries on staging.” — Why: measurable performance target.
Poor: “Login should be secure.” Good: “After 5 failed login attempts, account is locked for 15 minutes and an email is sent to the account owner.” — Why: explicit behavior and thresholds.
Poor: “Mobile layout should be responsive.” Good: “On devices ≤ 375px width, the hero image scales to 100% width and CTA remains visible above the fold.” — Why: specific viewport and behavior.

Integrating acceptance criteria into your workflow (practical suggestions)

Acceptance criteria are most effective when they are part of a living process, not a static doc.

Add acceptance criteria to every user story before sprint planning ends — block the story if criteria are missing.
Automate where possible: map Gherkin statements to automated tests (Cucumber, SpecFlow) and run in CI to get quick feedback.
Use acceptance criteria as the agenda for demo and review: each criterion must be demonstrated and signed off.
Keep a shared template (docs or issue template) so every story follows the same structure and reduces cognitive load during review.

How to scale acceptance criteria across many teams

When multiple teams work on a product, consistency matters. Use these practical governance tips to scale without bureaucracy.

Create a lightweight acceptance criteria style guide with examples for common story types — keep it a single page.
Run monthly “acceptance quality” spot checks: sample 10 stories, score criteria for clarity, and report a single trend metric.
Designate a rotating QA ambassador per squad to mentor authors and keep criteria testable and consistent.

Checklist: Ready-to-use acceptance criteria review checklist

Use this short checklist in pull request reviews or sprint demos to catch issues early.

Are acceptance criteria present and attached to the story?
Is each item testable and measurable?
Does any criterion contain more than one behavior? If so, split it.
Have edge cases and negative paths been included?
Are automation tests or manual test steps linked to each criterion?

When to accept a story — a pragmatic acceptance rubric

Use this rubric to make acceptance decisions consistent across reviewers. Score each criterion: 0 (fail), 1 (partial), 2 (pass). Total possible points = number of criteria × 2. Require ≥90% to accept or otherwise specify remediation steps.

0 — criterion not met or behavior missing
1 — criterion met partially or with tolerable deviation (must be logged)
2 — criterion fully met and reproducible

Examples of acceptance criteria used as lead-generation touchpoints

You can turn acceptance criteria artifacts into content for stakeholders and prospects. Practical examples often double as trust signals.

Publish anonymized case-study acceptance criteria and results (e.g., “Reduced production defects by 40% using Gherkin-driven acceptance tests”).
Offer downloadable acceptance criteria templates (Gherkin + checklist) in exchange for an email to build a lead list.
Share a one-page acceptance criteria style guide as a gated asset during sales demos to demonstrate process maturity.

Wrap-up: the most important rules to remember

Summing up into five rules you can memorize and use immediately:

Make acceptance criteria testable and measurable.
Keep one behavior per criterion.
Include happy and unhappy paths.
Avoid prescribing implementation details.
Link each criterion to a demonstrable test — manual or automated.

Next steps — quick checklist to improve your team’s acceptance criteria this week

Pick 1–2 items below and commit to them in your next retrospective to drive immediate improvement.

Adopt a single acceptance criteria template for all stories this sprint.
Automate one Gherkin scenario and run it in CI.
Run a 15-minute session to rewrite the top 5 ambiguous acceptance criteria in your backlog.

FAQ

What’s the difference between acceptance criteria and acceptance tests?

Acceptance criteria are written statements that define expected behavior; acceptance tests are the executable checks (manual steps or automated scripts) that verify those criteria. Think of criteria as the contract and tests as proof you met it.

How many acceptance criteria should a story have?

There’s no fixed number. Aim for as many criteria as needed to cover behavior, edge cases, and non-functional targets without merging multiple behaviors into a single item. A typical story has 3–8 acceptance criteria.

Can acceptance criteria include implementation constraints?

Preferably not. Criteria should state expected outcomes, not how to build them. Include implementation constraints only when there are regulatory or architectural requirements that are non-negotiable.

Should designers and QA write acceptance criteria too?

Yes. Acceptance criteria are most effective when they’re co-created by product, design, and QA so they reflect user goals, visual expectations, and testability from the start.

How do I measure improvement in acceptance criteria quality?

Track metrics like number of acceptance-related reopens, defects traced back to ambiguous criteria, and time-to-accept. Small improvements—reducing reopens by 25% in two sprints—is a realistic target.