Acceptance criteria examples for non-technical founders

In short: an acceptance criterion is a check that a non-developer can run and that ends in pass or fail. Write them before the build, one set per must-have requirement, and use the Given / When / Then pattern when a behaviour has conditions. Below are examples for ten common features, and the test that separates a real criterion from a wish.

The test

For each criterion ask: could two people run this and disagree about whether it passed? If yes, it is not finished. Words such as "fast", "easy", "intuitive", "secure" and "efficient" are wishes. Replace them with a number, a state or an observable event.

The pattern

Given a starting state, when the user does something, then a specific result is observable. It keeps each criterion short and testable.

Ten examples

1. Sign-in

• Given a registered user, when they enter a correct email and password, then they reach their dashboard in under 3 seconds.
• Given a wrong password entered 5 times in a row, when they try a 6th time, then the account is locked for 15 minutes and the user is told so.

2. Password reset

• Given a registered email, when the user requests a reset, then an email arrives within 2 minutes with a link that works once and expires after 60 minutes.
• Given an unregistered email, when the user requests a reset, then the screen looks identical to the registered case (no account disclosure).

3. Search

• Given 10,000 records, when the user types a search term, then results appear in under 2 seconds and are sorted by relevance.
• Given a term with no matches, then the user sees an explicit "no results" message with a way to clear the search.

4. Role permissions

• Given a user with the "viewer" role, when they open an edit page by direct URL, then they are refused and nothing is changed.
• Given a user whose role is changed, then the new permissions apply at their next request, without signing out.

5. File upload

• Given a PDF under 10 MB, when uploaded, then it appears in the list within 5 seconds with its name and size.
• Given a file whose real type differs from its extension (for example a script renamed .jpg), then it is rejected.

6. Payment

• Given a successful payment, then the order status becomes "paid" and a receipt is emailed within 2 minutes.
• Given a declined card, then no order is created and the user can retry without re-entering the cart.

7. Notifications

• Given a status change, then every subscribed user gets a notification within 1 minute, once, not repeatedly.

8. Export

• Given a filtered list, when the user exports, then the file contains exactly the rows currently shown, with the same columns, in a format Excel opens without errors.

9. Data migration

• Given the legacy data set, after migration the record counts per table match the source, and a sample of 50 records chosen by the client match field by field. On one migration of three years of budget history, the check was that balances matched the original ledger with no drift.

10. Offline behaviour

• Given no network connection, when the user records an item, then it is saved on the device and synchronises automatically on reconnection, with no duplicate.

Where criteria usually go missing

• Error states. What happens when the card is declined, the file is too large, the network drops? Vendors demo the happy path; criteria force the rest into the contract.
• Permissions. Test what each role cannot do, not just what it can.
• Data. Migration and export are the features most often discovered at the end.

On one build I reviewed, three of six sprints were only partially delivered because the vendor had been demoing the happy path and deferring error handling, permissions and data migration to a phase that did not exist in the contract. Criteria written beforehand would have exposed it in sprint one.

Who writes them

You do, with help. The business owner knows what "done" means; someone technical makes it testable. The PRD template shows where acceptance criteria sit in a specification, and the Technical Specification & PRD offer writes them with you before any vendor is chosen. Once a build is running, Build Oversight grades each sprint against them.