“Acceptance Criteria Examples: 15+ Real Samples You Can Copy”

What are acceptance criteria?

acceptance criteria examples is a key topic in modern project management and teamwork. Acceptance criteria are the specific, observable conditions that must be true for a user story to be accepted by the product owner. They define scope, describe expected behaviour, and give testers a basis for test design.

They are not a requirements document and not a test plan. A criterion describes an outcome from the user’s or system’s perspective; a test case describes the steps and data used to verify it. One criterion can generate several test cases once you add boundaries, permissions and failure paths.

The distinction that causes the most confusion is acceptance criteria versus definition of done. Acceptance criteria are local to a story: this export must contain only records the user can access. Definition of done is global: code reviewed, tests passing, documentation updated, deployed to staging. A story is complete only when both are satisfied, and mixing them produces checklists that say “unit tests written” next to “user sees an error message”, which are not the same kind of statement.

Checklist or Given-When-Then: which format should you use?

Use a checklist when the story is a set of rules that hold regardless of context, and use Given-When-Then when behaviour changes with state, permissions, timing or sequence.

The hybrid is what mature teams actually use. A file upload story might have four checklist rules about size and type, plus two scenarios for what happens when a user uploads a virus-positive file while a scan is still running.

What makes an acceptance criterion testable?

A criterion is testable when two people can independently judge pass or fail and reach the same conclusion, using only the criterion and the product.

Four tests catch most bad criteria. Is there a number, a named state or an observable event? Would a tester know what data to use? Is the outcome stated rather than the implementation? Can it fail? If a criterion cannot fail, it is not a criterion; it is a slogan.

“Export should be fast” fails all four. “Exporting 10,000 rows completes within 30 seconds on the reference dataset” passes all four: it has a number, a dataset, an observable outcome and a clear failure condition.

INVEST, Bill Wake’s checklist for user stories, ends with T for testable, and that is not an accident. If the team cannot describe how they would verify a story, the story is not ready for estimation regardless of how well it is written.

17 acceptance criteria examples you can copy

The examples below are grouped by the kind of risk they address. Each gives the story, one or two criteria, and the format used. Adapt names, limits and messages to your product.

1. Sign in with account lockout (Given-When-Then)

Story: As a registered customer, I want to sign in so I can access my account.

• Given a registered account with no failed attempts, When the user enters the correct password, Then they reach the dashboard and a session is created.
• Given three consecutive failed attempts within 15 minutes, When the user tries a fourth time, Then the account is locked for 30 minutes and the message names the unlock path.
• Given a locked account, When the user requests a password reset, Then the lock is cleared after a successful reset.

This example shows why state matters. A checklist could state “account locks after three failures”, but only a scenario captures what happens when a locked user resets their password, which is exactly where support tickets come from.

2. Password reset link expiry (checklist)

Story: As a user, I want to reset my password so I can regain access.

• It is done when the reset link expires 60 minutes after it is issued.
• It is done when an expired link shows an error and offers to send a new link.
• It is done when a used link cannot be reused, even within the expiry window.
• It is done when the new password must differ from the previous three passwords.

3. CSV export respects permissions (Given-When-Then)

Story: As a regional manager, I want to export the selected reporting period so I can prepare a stakeholder update.

• Given I have export permission, When I export a period with accessible records, Then the CSV contains only records I can access.
• Given I lack export permission, When I request an export, Then no file is generated and the action is logged.
• Given the period has no matching records, When I export, Then I see an explanation instead of an empty file.

4. Change a workspace role (checklist)

Story: As a workspace administrator, I want to change a member’s role so access matches their responsibilities.

• It is done when only owners can assign the owner role.
• It is done when demoting the last owner is blocked with a message naming the constraint.
• It is done when the change appears in the audit log within 5 seconds.
• It is done when the affected user’s next request reflects the new role without re-login.

5. Remove a saved payment card (checklist)

Story: As a customer, I want to remove a saved card so my payment methods stay current.

• It is done when a card can be removed from the payment methods page.
• It is done when removing the default card asks which remaining card becomes default.
• It is done when a card linked to an active subscription cannot be removed, and the message names the subscription.
• It is done when existing payment tests pass unchanged.

6. Apply a discount code (Given-When-Then)

Story: As a shopper, I want to apply a discount code so I can see the final price before paying.

• Given a valid percentage code, When I apply it to a cart of $120, Then the total shows the discount and the recalculated tax in the same view.
• Given an expired code, When I apply it, Then the cart total is unchanged and the message states the expiry date.
• Given a code limited to one use per account, When I apply it a second time, Then it is rejected with the reason.

7. File upload validation (checklist)

Story: As a project member, I want to attach files to a task so the team has the source material.

• It is done when files larger than 25 MB are rejected before upload starts.
• It is done when unsupported extensions are rejected with the allowed list shown.
• It is done when a failed upload can be retried without re-selecting the file.
• It is done when the upload progress reflects actual bytes transferred, not an animation.

8. Search with filters (Given-When-Then)

Story: As a support agent, I want to search tickets by status and owner so I can find the right case quickly.

• Given 400 open tickets and 120 closed, When I filter by open status, Then the result count shows 400 and the first page loads within 2 seconds.
• Given a filter combination with no matches, When the search runs, Then an empty state explains which filters are active and offers to clear them.
• Given I navigate away and return, When the page reloads, Then my filters persist for the session.

9. Scheduled report delivery (checklist)

Story: As an operations lead, I want a weekly report emailed so I stop rebuilding it manually.

• It is done when the schedule runs in the workspace time zone, not the server time zone.
• It is done when a failed delivery retries twice and then notifies the report owner.
• It is done when the email links to the live report rather than attaching a stale file.
• It is done when changing the schedule takes effect from the next run, not immediately.

10. Account deletion with grace period (Given-When-Then)

Story: As a customer, I want to delete my account so my data is removed.

• Given an active account, When the user confirms deletion, Then the account is deactivated immediately and permanently deleted after 30 days.
• Given a deactivated account, When the user signs in within 30 days, Then the account is restored with its data intact.
• Given a permanent deletion, When the 30 days elapse, Then the audit log retains the deletion event without personal data.

11. API rate limiting (checklist)

Story: As an API consumer, I want predictable rate limits so I can design retries correctly.

• It is done when the limit is 600 requests per minute per key.
• It is done when exceeding the limit returns HTTP 429 with a Retry-After header.
• It is done when limits are counted per key, not per IP address.
• It is done when the limit resets on a rolling 60-second window.

12. Bulk import validation (Given-When-Then)

Story: As an administrator, I want to import users from CSV so onboarding does not take a day.

• Given a CSV with 500 valid rows, When I import, Then all 500 users are created and the summary reports 500 successes.
• Given a CSV with 3 invalid rows, When I import, Then 497 users are created and the report lists the 3 rows with line numbers and reasons.
• Given a duplicate email within the file, When I import, Then the first occurrence wins and the duplicate is reported, not silently merged.

13. Offline mobile capture (checklist)

Story: As a field technician, I want to record inspection results offline so I can work without signal.

• It is done when records created offline are stored locally and marked pending.
• It is done when sync retries automatically when connectivity returns.
• It is done when conflicting edits show both versions and require a choice.
• It is done when pending records survive an app restart.

14. Keyboard-only navigation (Given-When-Then)

Story: As a keyboard user, I want to complete checkout without a mouse so I can use the product independently.

• Given focus is in the cart, When I press Tab, Then focus moves through every interactive element in visual order with a visible indicator.
• Given a modal is open, When I press Escape, Then the modal closes and focus returns to the button that opened it.
• Given a form error, When it appears, Then it is announced to assistive technology and focus moves to the first invalid field.

15. Audit log retention (checklist)

Story: As a compliance officer, I want administrative actions logged so audits are defensible.

• It is done when every role change, export and deletion is recorded with actor, timestamp and target.
• It is done when logs are immutable for 12 months.
• It is done when log exports exclude passwords, tokens and personal data.
• It is done when a log query for 90 days returns within 10 seconds.

16. Multi-currency rounding (Given-When-Then)

Story: As a finance user, I want consistent rounding so invoices reconcile.

• Given a line total of 33.335 in a two-decimal currency, When the invoice is generated, Then the line shows 33.34 and the total equals the sum of rounded lines.
• Given a currency with zero decimals, When the amount is 1,250.6, Then the invoice shows 1,251 and no decimal separator.
• Given a refund of a rounded line, When it is processed, Then the refund equals the rounded amount originally charged.

17. Notification preferences (checklist)

Story: As a user, I want to control notifications so I am not flooded.

• It is done when email, push and in-app channels can be set independently.
• It is done when disabling a channel takes effect within one delivery cycle.
• It is done when transactional security alerts cannot be disabled.
• It is done when changes are reflected across devices after refresh.

How many acceptance criteria should one story have?

Three to seven criteria is the practical range; fewer than three usually means edge cases were never discussed, and more than seven usually means the story is hiding two or three stories inside it.

A useful diagnostic: if the criteria list contains the word “and” in the story title, split the story. “User can export and schedule reports” is two stories with different failure modes, different test approaches and probably different owners.

When a story genuinely needs more than seven criteria, group them by risk rather than by feature. One group for permissions, one for validation, one for failure recovery. If a group has no criteria, that is your blind spot.

What do good criteria cost, and what do bad ones cost?

Good criteria cost minutes in refinement; bad criteria cost hours in rework, and the multiplier grows with each stage they survive.

Consider a concrete case. A story says “users can export their data”. In refinement, the team spends 20 minutes writing six criteria and discovers two unresolved decisions: whether exports include deleted records, and whether a viewer can export. Those are product decisions, not engineering ones, and resolving them takes 15 minutes with the product owner.

If the story proceeds without them, the developer picks an interpretation, the tester writes tests against a different one, and the mismatch surfaces in sprint review. Rework costs roughly 2 hours across development, testing and review. If the ambiguity survives to production, the support ticket, hotfix and release cycle typically consume 6 to 8 hours.

Now scale it. A team with 12 stories per sprint and a 30% ambiguity rate has roughly four stories per sprint carrying unresolved decisions. At 2 hours of rework each, that is 8 hours per sprint, or about 200 hours a year, before counting the trust cost of repeated “that is not what I meant” conversations.

How do acceptance criteria connect to test cases?

One criterion usually produces three to five test cases once you add the happy path, boundaries, permissions and failure recovery, which is why criteria quality drives test coverage more than test case quantity does.

Take the lockout criterion: “three consecutive failed attempts within 15 minutes locks the account for 30 minutes”. A tester derives at least six cases: two failures then success, exactly three failures, three failures spread over 16 minutes, a locked account attempting login, a locked account resetting the password, and a lock expiring at 30 minutes. Every one of those cases exists because the criterion contained numbers and states.

If the criterion had said “the account locks after too many failed attempts”, the tester would have written one case, and the boundary defects would have shipped.

What mistakes make acceptance criteria useless?

Six mistakes recur across teams, and each has a cheap fix.

Writing implementation details instead of outcomes is the first: “the button calls the /export endpoint” describes a solution, not behaviour. Using unmeasurable adjectives is the second: fast, intuitive, user-friendly and secure all need numbers or named states. Mixing definition-of-done items into story criteria is the third. Writing criteria after development is the fourth, which turns them into a description of what was built. Omitting negative paths is the fifth, and it is where most production defects live. Letting criteria grow without splitting the story is the sixth.

The cheapest fix for all six is a review step. Before a story is estimated, a developer and a tester read the criteria aloud and ask one question: how would we prove this? If the answer takes more than a sentence, the criterion is not ready.

Where do acceptance criteria live in your tool?

Criteria need to be visible at the point of work, not buried in a document that nobody opens during the sprint, and they need a clear pass or fail state at review.

In Doitify, a story can carry multi-level tasks and sub-tasks, a checklist for the criteria, and a quality-control stage that must be completed before the task moves to review, so the criteria are part of the workflow rather than a separate page. Acceptance criteria and definition-of-done items can sit in different checklist groups, which keeps local conditions separate from team-wide standards. Doitify is our product and this is a disclosure; the practice works in any tracker that supports checklists and a review state, and the tool will not fix vague criteria.

Whichever tool you use, keep three things together: the story, the criteria, and the evidence that each criterion passed. When those three are separate, acceptance becomes an opinion.

Conclusion

Acceptance criteria are cheap to write and expensive to skip. They turn a story from an intention into a contract between product, development and testing, and they surface unresolved decisions while those decisions still cost minutes.

Start with the format that matches the risk: a checklist for rules, scenarios for state. Keep the count between three and seven, make every line pass or fail, and review the criteria with a developer and a tester before estimation. The examples above are patterns, not policy; the only rule that matters is that everyone would recognise the same “done”.

If this post on acceptance criteria examples was helpful, you might also enjoy Project Timeline vs Gantt Chart: Key Differences (When to Use Each) and Project Resource Management: Complete Guide.