Avoid Vague Language: Acceptance Criteria Examples Ready to Copy

Acceptance criteria are the explicit, testable conditions that must be true before a user story counts as done. Below you’ll find ready-to-copy examples and blank templates organized by feature type: login and authentication, checkout, search, APIs, data imports, and notifications. Each one is written to be testable, not aspirational, so you can drop it straight into a ticket.

TL;DR:

• Acceptance criteria should specify testable and objective conditions, such as locking an account after five failed login attempts or displaying error messages for invalid inputs.
• Using the Given/When/Then format is ideal for multi-step flows and automating tests, while checklists suit simple, independent conditions.
• Clear criteria reduce scope ambiguity, prevent scope creep, and ensure quotes are based on precise requirements, especially for external development.
• Especially for complex features like API responses or data imports, acceptance criteria must define exact thresholds, error handling, and edge cases upfront.
• Writing criteria during backlog refinement, rather than at the last minute, yields more complete, actionable, and testable specifications.

Table of Contents

• What Are Acceptance Criteria (And How Do They Differ From User Stories)?
• Why Do Acceptance Criteria Matter for Delivery and QA?
• Which Acceptance Criteria Format Should You Use?
• Acceptance Criteria Examples by Feature Type
• How Do You Write Testable Acceptance Criteria?
• What Mistakes Should You Avoid When Writing Acceptance Criteria?
• Blank Acceptance Criteria Templates You Can Copy
• A Pragmatic Note on Detail Versus Speed
• Ready to Hand These Criteria to a Developer?
• Sources
• FAQ

What Are Acceptance Criteria (And How Do They Differ From User Stories)?

Acceptance criteria describe the “what,” not the “how.” They spell out the conditions a feature must satisfy to be considered complete and accepted by the user, without dictating the technical approach a developer takes to get there. A user story captures intent: “As a returning customer, I want to save my shipping address so I don’t retype it every order.” Acceptance criteria then define exactly what “done” looks like for that story, in specific, checkable terms.

The definition of done is a separate artifact again. It applies to every story on the board, covering things like code review, test coverage, and documentation. Acceptance criteria are story-specific. A checkout story and a search story both need to satisfy the same definition of done, but each has its own unique acceptance criteria.

Who writes them varies by team. Product owners typically draft the first pass during backlog refinement, developers and QA refine the edge cases, and the whole team reviews them before a story enters a sprint. Waiting until the story is already coded is the most common timing mistake, according to Scrum Alliance’s guidance on the topic.

Why Do Acceptance Criteria Matter for Delivery and QA?

Clear acceptance criteria eliminate the guessing game between what a stakeholder imagined and what a developer built. Every assumption you leave unwritten becomes a decision someone else makes for you, usually the wrong one.

Testability is the real payoff. A criterion written as an observable condition (“the system displays an error message when the field is empty”) converts directly into a QA test case or an automated test script. Vague criteria (“the form should work well”) can’t be automated because nobody can agree on what “well” means.

This has direct financial consequences if you’re sourcing development work externally; see this guide to evaluate software for financial teams to ensure performance, security, and audit expectations are met. Fuzzy requirements produce fuzzy quotes: vendors pad estimates to cover unknowns, or worse, they under-quote and then bill you for “scope creep” that was actually just an unwritten requirement. Well-specified acceptance criteria let developers quote against the same brief, which makes comparing bids far more honest.

Which Acceptance Criteria Format Should You Use?

Pick the format based on the shape of the behavior you’re describing, not personal preference.

Given/When/Then (Gherkin) works best when a feature has a clear precondition, a triggering action, and an observable result. It scales especially well for behaviors with multiple paths and edge cases, and it’s the format most compatible with behavior-driven development tools, since each scenario can become an automated test almost verbatim.

Checklist format is faster to write and easier to skim when a story has a handful of independent, simple pass/fail conditions. Nobody needs three lines of Gherkin to say “the submit button is disabled until all required fields are filled.”

Rule-based format fits business logic and eligibility rules, where the criteria describe conditions and outcomes rather than user actions. Discount eligibility, tax calculation, and access permissions are classic candidates, and Tricentis identifies this as the right choice whenever policy logic, not user flow, drives the behavior.

Hybrid criteria combine formats within a single story. A checkout story might use Gherkin for the primary purchase flow and a rule-based block underneath for discount stacking logic. There’s no rule against mixing them; the goal is clarity, not purity.

• Use Gherkin for multi-step flows and anything headed for test automation.
• Use a checklist for simple, independent, low-ambiguity conditions.
• Use rule-based criteria for eligibility, pricing, and permission logic.
• Combine formats within one story when different parts of the behavior call for different structures.

Acceptance Criteria Examples by Feature Type

These examples are close to production-ready. Adjust field names, thresholds, and messages to match your own product, but the structure and level of specificity should carry over directly.

1. Authentication: login lockout

Given a user has entered an incorrect password 5 times in a row
When they attempt to log in again
Then the account is locked for 15 minutes
And the system displays "Too many attempts. Try again in 15 minutes."
And a lockout event is logged with timestamp and IP address

2. Authentication: password reset

Given a user requests a password reset with a valid registered email
When they submit the request
Then a reset link is sent to that email within 60 seconds
And the link expires after 30 minutes
And the link can only be used once

3. E-commerce: discount code application

Given a customer has items in their cart totaling $50 or more
Then the cart total updates to reflect the discount immediately
And the discount does not apply to shipping costs
And an expired or invalid code shows "This code is no longer valid."

4. E-commerce: insufficient stock at checkout

Given an item in the cart has less inventory than the quantity requested
When the customer proceeds to payment
Then checkout is blocked
And the system displays the available quantity
And the customer can adjust quantity without losing other cart items

5. Search: exact and partial match handling

Given a user searches for a product name
When there is an exact match
Then the exact match appears first in results
When there is no exact match
Then results include partial matches ranked by relevance
And a search with zero results displays "No products found for [query]" with a suggestion to browse categories

6. Search: pagination

• Results are paginated at 24 items per page.
• Page number persists in the URL so results are shareable and bookmarkable.
• Navigating to a page beyond the last available page redirects to the last valid page.

7. API endpoint: response and error handling

Given a GET request to /orders/{id} with a valid order ID
When the order exists
Then the API returns a 200 status with the order object in JSON
Given the order ID does not exist
Then the API returns a 404 status with an error payload: {"error": "Order not found"}
Given more than 100 requests are made from one client in 60 seconds
Then the API returns a 429 status with a "Retry-After" header

Criteria like these matter most once you’re past prototyping and into a real backend. If you’re scoping an API integration build, writing the error and rate-limit behavior into acceptance criteria up front saves a full round of clarifying questions later.

8. Data processing: CSV import

Given a user uploads a CSV file matching the required template
When all rows pass validation
Then all records are imported and a success summary shows the row count
Given some rows fail validation (missing required field, invalid format)
Then valid rows are imported and invalid rows are skipped
And a downloadable error report lists the row number and reason for each failure
Given the file fails to parse entirely
Then no records are imported and the full import is rolled back

9. Notifications: delivery and retry

Given a triggering event occurs (order shipped)
When the notification service sends an email
Then delivery is attempted within 2 minutes of the event
Given the first delivery attempt fails
Then the system retries up to 3 times over 30 minutes
And if all retries fail, the notification is logged as undelivered
And a user who has opted out of shipping notifications does not receive the email

How Do You Write Testable Acceptance Criteria?

Run every draft criterion through this checklist before it goes into a sprint. A practical checklist should require single-behavior statements, measurable outcomes, and explicit edge cases, and each item below maps to exactly one of those requirements.

• Does this criterion describe one behavior, not several bundled together?
• Is the outcome observable? Could a tester verify it without asking the developer how it works?
• Are thresholds and limits stated as numbers, not adjectives (“15 minutes,” not “quickly”)?
• Are edge cases covered: empty input, invalid input, boundary values, concurrent access?
• Are performance or security constraints stated where they apply, not assumed?

If a criterion is unclear even after review, ask for a concrete example rather than more abstract wording. Requesting a specific instance, like “what exactly counts as an eligible user?”, tends to surface hidden assumptions faster than rewording the requirement in the abstract.

Here’s a before and after. Vague: “The search should be fast and return good results.” Testable: “Given a search query of 3 or more characters, the system returns results within 500 milliseconds, ranked by relevance score, with exact matches listed first.”

Pro Tip: Write acceptance criteria the same week the story enters refinement, not the day before sprint planning. Criteria written under deadline pressure tend to skip edge cases, and those gaps become the bugs QA finds two sprints later.

Each well-formed criterion becomes a QA test case almost directly: the “Given” sets up test data, the “When” is the test action, and the “Then” is the assertion. That’s the whole reason testability matters more than eloquence here.

What Mistakes Should You Avoid When Writing Acceptance Criteria?

1. Vague language. “The page should load quickly” tells a tester nothing to check against. Rewrite it as “the page loads within 2 seconds on a standard broadband connection.”
2. Multiple behaviors crammed into one criterion. “The user can log in and reset their password and update their profile” is three stories pretending to be one line. Split each behavior into its own criterion.
3. Happy-path tunnel vision. A criterion that only covers the successful case leaves every failure mode undefined. Add a corresponding negative case for every positive one, such as invalid input, expired sessions, or empty states.
4. Implementation detail leakage. “Use a Redis cache to store the session” tells the developer how, not what. Acceptance criteria should describe the observable result (“the user stays logged in for 24 hours of inactivity”), not the technology used to deliver it.

Blank Acceptance Criteria Templates You Can Copy

Paste these directly into a ticket and fill in the brackets.

Gherkin template:

Given [a starting condition or system state]
When [the user or system performs an action]
Then [the expected, observable outcome]
And [any additional outcome, if needed]

Checklist template:

- [Behavior] happens when [condition].
- [Field/button] is disabled/hidden when [condition].
- An error message reading "[exact text]" appears when [condition].

Rule-based template:

IF [condition A] AND [condition B]
THEN [outcome]
UNLESS [exception], IN WHICH CASE [alternate outcome]

Most stories need somewhere between three and seven criteria. Fewer than three usually means the story is too thin to test properly; more than seven usually means it should be split into smaller stories.

A Pragmatic Note on Detail Versus Speed

Every extra line of acceptance criteria costs refinement time, and not every story earns that cost. A simple copy change doesn’t need Gherkin. A payment flow does.

The real skill is knowing which stories are cheap to leave loose and which ones will bite you in QA if you do. Concrete examples, not more prose, are usually what closes that gap fastest. When a criterion still feels shaky after a full pass, a five-minute conversation with the developer beats another round of edits nobody’s confident in.

— 5Quotes

Ready to Hand These Criteria to a Developer?

Well-written acceptance criteria are only half the job. The other half is finding a developer who reads them the way you intended, and quotes accordingly. There are services designed to help you post your project with acceptance criteria and receive tailored quotes from qualified developers, instead of chasing down agencies one by one and hoping their estimates are comparable.

Because every developer on the platform is quoting against the same brief, tightly specified criteria translate into tighter, more comparable quotes, not the padded estimates that show up when scope is left to interpretation. Whether you’re specifying a checkout flow, an API integration, or a full custom software build, clearer acceptance criteria mean less back and forth before work even starts. Post your project and get your software development quote with the criteria you’ve already written, and let developers respond to specifics instead of guesswork.

Sources

• What is Acceptance Criteria? Definition, Examples, & Tips — Atlassian
• Acceptance Criteria Examples — 20 Real-World Templates You Can Copy — Spec Coding
• Refine user stories and acceptance criteria with Agile — Pluralsight (Mountain Goat Software guidance)
• What you need to know about acceptance criteria — Tricentis
• Acceptance Criteria for User Stories — Mountain Goat Software

FAQ

What Are Some Examples of Acceptance Criteria?

Common examples include login lockout rules (“account locks after 5 failed attempts”), checkout conditions (“checkout blocks when stock is insufficient”), and API behavior (“returns 404 with an error payload when a resource doesn’t exist”). See the domain-by-domain examples above for full Gherkin and checklist versions.

What Are Some Examples of Acceptance Criteria Templates?

The three most useful templates are Given/When/Then (Gherkin) for multi-step behaviors, a checklist for simple pass/fail conditions, and a rule-based IF/THEN/UNLESS template for business logic like eligibility or pricing.

Can You Provide an Example of a User Story With Acceptance Criteria?

A story might read: “As a shopper, I want to apply a discount code so I pay less at checkout.” Its acceptance criteria would specify the minimum cart value, how the discount displays, and what happens with an invalid code, as shown in the e-commerce examples above.

Can You Provide Examples of Given/When/Then Acceptance Criteria?

Yes. One example: “Given a user has entered an incorrect password 5 times in a row, When they attempt to log in again, Then the account is locked for 15 minutes.” The authentication and checkout examples above include several more in the same format.

Recommended

• Technical Consulting New Zealand
• CI/CD Pipeline Setup New Zealand
• AI Development & Automation New Zealand
• AI Strategy Consultants New Zealand