Acceptance Criteria Examples for Software Teams

Acceptance criteria examples help product owners, founders, developers, and QA teams understand what a feature must do before it can be accepted as complete. Instead of leaving requirements open to interpretation, acceptance criteria turn expectations into clear, testable conditions.

If you need the full definition first, read our guide on what acceptance criteria are. This page focuses on practical examples you can adapt for real software projects.

Acceptance criteria can be written in different formats. The most common are Given/When/Then, often used in Gherkin syntax, and a rule-based checklist format. The official Cucumber Gherkin reference is a useful external guide for teams that want to use structured scenarios in testing and behaviour-driven development.

How to use these acceptance criteria examples

Use these examples as a starting point, not as final copy for every project. Good acceptance criteria should reflect your users, product rules, edge cases, and business goals.

For each example below, you’ll see:

Given/When/Then: Best for user actions, workflows, and system responses.

Checklist format: Best for rules, validations, and simple conditions.

User story acceptance criteria examples

1. Login

Given/When/Then:

Given the user has a registered account, when they enter a valid email and password, then they are logged in and redirected to the dashboard.

Checklist:

1. Valid users can log in.
2. Invalid credentials show an error.
3. Locked accounts cannot log in.
4. Successful login redirects to the dashboard.

2. Password reset

Given/When/Then:

Given the user forgets their password, when they request a reset link with a registered email, then the system sends a password reset email.

Checklist:

1. Reset link is sent to registered emails.
2. Link expires after 30 minutes.
3. Unregistered emails show a safe generic message.
4. New password must meet security rules.

3. Task filtering

Given/When/Then:

Given the user is viewing tasks, when they select “completed,” then only completed tasks are displayed.

Checklist:

1. Tasks can be filtered by status.
2. Empty results show an empty state.
3. Filters can be cleared.
4. Selected filters remain visible.

Feature acceptance criteria examples

4. Search feature

Given/When/Then:

Given the user enters a search term, when they submit the search, then matching results are displayed by relevance.

Checklist:

1. Search returns matching records.
2. No results show a helpful message.
3. Search ignores unnecessary spaces.
4. Results load within an agreed time.

5. Notification preferences

Given/When/Then:

Given the user opens notification settings, when they turn off email alerts, then the system stops sending email notifications.

Checklist:

1. Users can enable or disable email alerts.
2. Changes are saved immediately.
3. Users see confirmation after saving.
4. Preferences apply to future notifications.

6. Invoice download

Given/When/Then:

Given an invoice is available, when the user clicks “Download PDF,” then the invoice downloads in PDF format.

Checklist:

1. Invoice downloads as a PDF.
2. File name includes invoice number.
3. Only authorised users can download.
4. Failed downloads show an error message.

7. Admin user management

Given/When/Then:

Given an admin is viewing the user list, when they deactivate a user, then the user can no longer access the system.

Checklist:

1. Admins can deactivate users.
2. Deactivated users cannot log in.
3. Admins see a confirmation prompt.
4. The action is recorded in the audit log.

Form acceptance criteria examples

8. Contact form

Given/When/Then:

Given the visitor completes the contact form, when they submit it, then the message is sent and a success message appears.

Checklist:

1. Required fields must be completed.
2. Invalid email format shows an error.
3. Successful submissions show confirmation.
4. Form data is sent to the correct inbox or CRM.

9. Signup form

Given/When/Then:

Given a new user enters valid signup details, when they submit the form, then the account is created.

Checklist:

1. Email must be unique.
2. Password must meet rules.
3. Terms must be accepted.
4. User receives a welcome email.

10. Payment form

Given/When/Then:

Given the user enters valid payment details, when they confirm payment, then the payment is processed and a receipt is generated.

Checklist:

1. Valid cards are processed.
2. Failed payments show a clear message.
3. Duplicate payments are prevented.
4. Receipt is sent after success.

11. Booking form

Given/When/Then:

Given the user selects an available time slot, when they confirm the booking, then the slot is reserved.

Checklist:

1. Only available slots can be selected.
2. Confirmation is shown after booking.
3. User receives a booking email.
4. Booked slots are no longer available.

API acceptance criteria examples

12. Create customer API

Given/When/Then:

Given a valid API request is sent, when the customer data is accepted, then the API creates a new customer record.

Checklist:

1. Valid requests return 201 Created.
2. Missing required fields return 400.
3. Duplicate emails are rejected.
4. Response includes customer ID.

13. Authentication API

Given/When/Then:

Given the request includes valid credentials, when the API authenticates the user, then it returns an access token.

Checklist:

1. Valid credentials return a token.
2. Invalid credentials return 401.
3. Tokens expire after the agreed time.
4. Sensitive data is not returned.

14. Update order status API

Given/When/Then:

Given an authorised system sends a valid order status update, when the request is processed, then the order status is updated.

Checklist:

1. Authorised requests update status.
2. Invalid status values are rejected.
3. Response confirms the new status.
4. All updates are logged.

Non-functional acceptance criteria examples

15. Performance

Given/When/Then:

Given the dashboard has up to 1,000 records, when the user opens it, then the first view loads within 3 seconds.

Checklist:

1. Dashboard loads within 3 seconds.
2. Pagination is available for large data.
3. Loading state is displayed.
4. Performance is tested before release.

16. Security

Given/When/Then:

Given a user enters the wrong password five times, when the fifth attempt fails, then the account is temporarily locked.

Checklist:

1. Five failed attempts trigger a lock.
2. Lock lasts 15 minutes.
3. User sees a clear message.
4. Admins can review failed attempts.

17. Accessibility

Given/When/Then:

Given a user navigates with a keyboard, when they move through the form, then each field can be reached and submitted without a mouse.

Checklist:

1. Form supports keyboard navigation.
2. Fields have clear labels.
3. Error messages are readable.
4. Buttons have accessible names.

18. Availability

Given/When/Then:

Given the service is live, when users access it during business hours, then the system remains available within the agreed uptime target.

Checklist:

1. Uptime target is defined.
2. Downtime is monitored.
3. Critical alerts notify the team.
4. Users see a friendly error page during outages.

Acceptance criteria vs test cases

Acceptance criteria define what must be true before a feature is accepted. Test cases define how the QA team will verify those conditions.

For example, an acceptance criterion may say: “The user receives a reset link that expires after 30 minutes.” A test case would include the exact test steps, test data, expected result, and pass or fail status.

In simple terms, acceptance criteria guide the work. Test cases validate the work. Scrum Alliance also explains acceptance criteria as conditions that help teams understand when work can be accepted by the customer, product owner, or stakeholder.

Best practices for writing acceptance criteria examples

Keep each criterion clear, testable, and focused on the expected outcome. Avoid vague wording like “fast,” “simple,” or “user-friendly” unless you define what they mean.

Good acceptance criteria should include happy paths, failure states, validation rules, permissions, and edge cases. They should also be reviewed before development begins so the team can clarify scope early.

For format templates, see our guide on acceptance criteria formats. For the full topic overview, return to the acceptance criteria guide.

Final thoughts

Acceptance criteria examples make software requirements easier to understand, build, test, and approve. They reduce assumptions and give every team member a shared view of what success looks like.

For startups and businesses building custom software, this clarity protects budget, reduces rework, and improves delivery quality. If you are planning a new product, platform, or internal system, Wazobia Technologies can help you turn business requirements into clear, testable software scope. Explore our custom software partnership.

FAQ

1. What is an example of acceptance criteria?

An example is: “Given a user enters valid login details, when they submit the login form, then they are redirected to the dashboard.” This can also be written as a checklist with rules for valid login, invalid credentials, and account restrictions.

2. How many acceptance criteria should a user story have?

Most user stories need 3 to 7 acceptance criteria. Complex stories may need more, but too many criteria can mean the story should be split into smaller work items.

3. What is the best format for acceptance criteria?

The best format depends on the feature. Given/When/Then works well for workflows and user behaviour. Checklist format works well for rules, validations, and simple conditions.

4. Are acceptance criteria the same as test cases?

No. Acceptance criteria define the conditions a feature must meet. Test cases define the specific steps used to verify whether those conditions have been met.

5. Who writes acceptance criteria?

Acceptance criteria are usually written by the product owner, product manager, or business analyst, then reviewed with developers, QA testers, designers, and stakeholders.

6. Should acceptance criteria include edge cases?

Yes. Good acceptance criteria should include normal flows, error states, permissions, validations, and important edge cases so the feature can be properly built and tested.