Acceptance Criteria Examples for QA and Product Teams

Acceptance criteria are the conditions a story must satisfy before anyone can call it done — the shortest contract in the delivery process, and the one most often written ten minutes before refinement. When they are specific, QA can write test cases straight from the ticket and sign-off is a formality. When they are vague, the same ambiguity gets discovered three times: once by the developer guessing, once by the tester in review, and once by a customer in production.

This guide collects concrete examples with the reasoning behind them: what separates a usable criterion from a decorative one, the two formats worth standardizing on, and how criteria turn into the cases described in how to write QA test cases. If your team writes scenarios directly in Given/When/Then, the companion patterns are in BDD test cases.

What acceptance criteria are — and are not

A criterion states a condition that is either satisfied or not. It describes what must be true, not how to build it and not how thoroughly to test it.

Two boundaries cause most arguments. Criteria are not test cases: "email must be unique per workspace" is a criterion, while the cases probing casing, whitespace, soft-deleted accounts, and invitation collisions are test design. And criteria are not the Definition of Done: performance budgets, accessibility standards, and logging requirements belong in the team's standing DoD rather than being copy-pasted into every ticket.

When acceptance criteria are worth the effort

Not every unit of work needs a formal criteria block, and pretending otherwise is how teams end up writing ceremony they later ignore.

The last row is easy to skip and expensive to skip. "No observable change to the export format" is a real criterion, and it tells QA exactly what to compare before and after.

Good versus bad acceptance criteria

The difference is almost always specificity about the observable outcome. Here are rewrites of the patterns that show up most often.

The rewrites share an actor, a condition, and an outcome someone can observe without reading the code. A criterion a tester cannot mark failed is not a criterion; it is a preference.

Two formats worth standardizing on

Rule-based criteria

A bulleted list of conditions. Best for stories with several independent rules and no interesting sequencing.

Story: Restrict CSV export by role
 
Acceptance criteria
- An Owner or Admin can export the billing CSV for any date range in the last 24 months
- A Member sees the export control disabled with a tooltip explaining the required role
- A Viewer does not see the export control at all
- A direct request to the export endpoint from a Member or Viewer is rejected
- Every successful export writes an audit entry with the actor, range, and timestamp

Rule-based lists are fast to write and fast to scan. Their weakness is state: if a story depends on what happened before, the format hides it.

Scenario-based criteria

Given/When/Then, for stories where the starting state changes the outcome.

Given a Member has an export request pending approval
When the same Member requests a second export for an overlapping range
Then the second request is rejected as duplicate
And the pending request remains unchanged

Use scenarios for workflows, transitions, and rules that only apply in a particular state; use rules for everything else. Mixing both in one ticket is fine. Forcing every criterion into Given/When/Then is how refinement meetings get long without getting clearer.

Example: login and session criteria

Authentication attracts vague criteria because everyone assumes the behavior is obvious. It is not — products differ on lockouts, session lifetime, and what happens to existing sessions when a password changes.

Story: Email and password sign-in
 
Acceptance criteria
- A user with valid credentials and a verified email reaches the dashboard
- A user with valid credentials and an unverified email is blocked and offered a resend link
- Invalid credentials return the same generic message whether or not the email exists
- After 5 consecutive failures within 15 minutes, the account is locked for 15 minutes
- A locked account shows the remaining wait time and does not reveal whether the password was correct
- Successful sign-in creates a session that expires after 14 days of inactivity
- Changing the password invalidates all other active sessions
- "Remember me" extends inactivity expiry to 30 days and is off by default

Each line is a rule a tester can prove or disprove. The generic-message rule is the one teams most often leave out, and the one with a security consequence: without it, the login form becomes an account enumeration tool. The full suite that grows out of these rules is worked through in login test cases.

Example: checkout discount codes

Checkout criteria fail the other way: they describe the happy path in detail and leave every interaction rule unstated.

Story: Apply a discount code at checkout
 
Acceptance criteria
- A valid, unexpired code applies to the order subtotal before tax and shipping
- The discount and the resulting total are shown as separate lines in the summary
- An expired or unknown code is rejected without clearing the cart
- Only one code applies per order; entering a second code replaces the first after confirmation
- A code restricted to first-time customers is rejected for accounts with a prior completed order
- If the cart changes so the order no longer meets the code's minimum, the discount is removed and the customer is told why
- A code cannot reduce the payable total below zero; the remainder is not refunded or stored as credit

The last three rules are the ones that generate production incidents. "Only one code per order" sounds obvious until two teams implement stacking differently in the API and the UI, and "cannot reduce below zero" sounds paranoid until a percentage code meets a small cart and a fixed-amount code at the same time.

Converting acceptance criteria into test cases

Criteria and cases are not the same artifact, and the conversion is where coverage gaps appear or get closed.

1. List each criterion as a separate line. If one bullet contains two rules joined by "and," split it first.
2. Write the positive case proving the rule holds under normal conditions.
3. Write the refusal. For every rule that permits, limits, or validates, write the case proving the system says no — and that nothing persisted. Patterns are in negative test cases.
4. Identify the boundary. Any number implies at least three cases: below, at, and above. "Up to 50 projects" means 49, 50, and 51.
5. Ask what the criterion does not say. Concurrency, stale tabs, partial failures, and permissions are the usual silences.
6. Check enforcement layers. A rule enforced only in the UI is not enforced; add the API-level case.
7. Trace the cases back to the criterion they came from, so a later change to the rule finds every affected case.

Worked through on one line from the login example:

One criterion, six cases. That ratio is normal, and it is the reason criteria should not try to be a test plan.

Ambiguous criteria and how to fix them

Ambiguity is rarely deliberate. It comes from words that feel precise in a meeting and evaporate in a ticket. The repair is a question, not a rewrite by the tester alone.

When a criterion cannot be answered without opening the code, it is a question for product, not a research task for QA. Guessing produces a passing test for behavior nobody agreed to.

Common mistakes

1. Solution design in disguise. "Add a dropdown in the header with three options" constrains the implementation and says nothing about the outcome. State the behavior; let design and engineering choose the control.
2. Only the happy path. Criteria that never mention refusal, empty states, or limits guarantee those decisions get made silently during implementation.
3. Unbounded scope. A story with eighteen criteria is usually three stories. Split it before it enters a sprint.
4. Untestable adjectives. Intuitive, seamless, robust, performant. Replace each with a number or an observable outcome, or delete it.
5. Writing criteria after the pull request. At that point they are a transcript of what was built, not a specification, and they will never fail.
6. No owner for unanswered questions. An open question with nobody's name on it stays open until it becomes a bug.

Best practices

Refinement is the highest-leverage moment for all of this. A tester who reads criteria out loud and asks "what happens if this fails?" for each line will surface more design gaps in ten minutes than a review board will after the build.

Acceptance criteria checklist

• Each criterion states one rule with a named actor
• Every rule is observable and can be marked failed
• Numbers, limits, and time windows are explicit
• Refusal behavior is described for every permission or validation rule
• Empty, first-use, and error states are covered where relevant
• Timezone, currency, and locale assumptions are stated if they matter
• Enforcement expectations cover the API, not just the interface
• No implementation instructions or UI trivia
• Definition of Done items are not duplicated per ticket
• Open questions have an owner and a due date
• Each criterion can be traced to at least one test case

FAQ

Who should write acceptance criteria?

Product owns the intent, but the best criteria come out of a short conversation with a developer and a tester present. Product knows the rule, engineering knows which parts are ambiguous in the system, and QA knows which silences will become defects.

How many criteria should a story have?

Usually three to eight. Fewer often means rules are hiding in someone's head; many more usually means the story should be split so it can be finished and verified in one iteration.

Should acceptance criteria include non-functional requirements?

Only when they are specific to that story. A checkout story with a hard latency budget should state it. General accessibility, logging, and browser support belong in the Definition of Done, where they apply to everything without being retyped.

What is the difference between acceptance criteria and acceptance tests?

Criteria are the conditions; acceptance tests are the executable checks that prove them. One criterion typically produces several tests, and the mapping between them is what makes coverage arguments concrete instead of anecdotal.

Can acceptance criteria change during a sprint?

Yes, and the change should be explicit rather than absorbed in a Slack thread. Update the ticket, tell QA, and check whether existing cases still apply. Silent changes are the most common cause of a story that passes review and fails demo.

Do we still need a test case template if criteria are good?

Yes. Criteria say what must be true; cases record how it was verified, with data, steps, and results. The field definitions worth standardizing are in the QA test case template.

Summary

Good acceptance criteria are boring to read and impossible to misinterpret. They name an actor, state one rule, and describe an outcome someone can observe. They say what the system refuses as clearly as what it allows, they put numbers where numbers matter, and they leave implementation choices to the people implementing. Everything past that — the boundary cases, the concurrency probes, the API-layer enforcement checks — is test design, and it gets easier the more precise the criteria were.

The fastest improvement available to most teams is not a new template. It is putting a tester in the room while criteria are written and letting them ask, line by line, what happens when this fails.

CTA — close the gap between criteria and coverage

Once criteria are agreed, the tedious part is expanding each rule into positives, refusals, and boundaries without missing the silent ones. Paste the criteria into QA Workflow Assistant to get that first structured draft, then review it against the checklist above. Plan options are on pricing, and setup walkthroughs are in Docs.