Acceptance criteria are the pass/fail conditions a single feature must meet before the team can call it finished. The fastest way to learn to write them is to read good ones, so this guide gives you worked examples for common features (login, search, checkout, file upload, notifications), each in the format that suits it best. It then covers how to judge your own criteria and where acceptance criteria stop and the definition of done begins.
TL;DR
- Acceptance criteria describe what one user story must do, in observable and testable terms, and they are agreed before development starts.
- Pick the format by the logic: Given/When/Then for flows, a checklist for simple features, "If X, then Y" rules for business logic.
- A good criterion states an outcome a non-technical tester can verify, with numbers where possible, and never dictates how engineers build it.
- Acceptance criteria belong to one backlog item. The definition of done is a shared checklist for every item. A story is finished only when it meets both.
Table of Contents
- What acceptance criteria are, in one minute
- Three formats, and when each one fits
- Acceptance criteria examples by feature
- What separates good criteria from weak ones
- Acceptance criteria vs. definition of done
- Who writes them, and when
- Bring security and quality into the criteria
- Our perspective
- When you want a team to do this with you
- A repeatable process for your next story
- FAQ
- Sources
What acceptance criteria are, in one minute
Acceptance criteria are clear statements that define what "working" means for a single backlog item. They are agreed before implementation starts, and the team tests against them. That timing matters. Written after the code exists, they turn into a description of what was built rather than a statement of what the business needed.
The user story says who wants something and why. The criteria say how everyone will know the story is delivered. A story such as "As a returning customer, I want to reset my password so I can get back into my account" leaves a dozen questions open. How long is the reset link valid? What if the email is not registered? Can the old password still work? The criteria answer those questions on paper, while changing the answer is still cheap.
They also work as an agreement between buyer and builder. Practitioners often use them as the basis for milestone acceptance, because they make it plain when a deliverable has been met. If you hire an outside team, this is the document that prevents the "but I thought it would..." conversation at the end.
Three formats, and when each one fits
There are three common formats: Given/When/Then, a checklist, and rules written as "If X, then Y". None is better in general. Each suits a different kind of requirement.
| Format | Best for | Weak spot |
|---|---|---|
| Given/When/Then | User flows and anything you plan to automate as a test | Verbose for trivial features |
| Checklist | Small, simple features and UI details | Hides sequence and context |
| Rules ("If X, then Y") | Pricing, permissions, eligibility, validation logic | Hard to read for long rule sets |
Most real backlogs mix all three. A checkout story might use Given/When/Then for the payment flow, a checklist for what the confirmation screen shows, and rules for shipping thresholds.
Acceptance criteria examples by feature
Each example below pairs a user story with criteria. Notice that every line can be answered with a plain yes or no by someone who has never seen the code.
Example 1: Login (Given/When/Then)
User story: As a registered user, I want to log in with my email and password so I can see my account.
- Given I am on the login page and my account is active, when I enter the correct email and password and select "Log in", then I land on my dashboard.
- Given I am on the login page, when I enter a correct email with a wrong password, then I see an error that does not reveal which of the two fields was wrong, and I stay on the login page.
- Given I have entered a wrong password five times in a row, when I try a sixth time, then the account is locked for 15 minutes and I see a message saying so.
- Given I am logged in, when I have been inactive for 30 minutes, then I am logged out and asked to sign in again.
The lockout and timeout numbers are placeholders. Your product owner or security lead sets the real ones, but the point stands: a number turns an opinion into a test.
Example 2: Product search (checklist)
User story: As a shopper, I want to search the catalog by keyword so I can find a product quickly.
- Results appear after I press Enter or select the search icon.
- Each result shows a product image, name, price and availability.
- Results are sorted by relevance by default, and I can re-sort by price, low to high or high to low.
- A search with no matches shows a "no results" message and suggests browsing categories.
- Searching for a product name with a typo of one character still returns the product.
- The first page of results loads in under 2 seconds on a standard broadband connection.
This is the kind of feature where a checklist is enough. Atlassian makes a similar point in its own product search example: tie the story to specific, measurable conditions that define what done looks like.
Example 3: Checkout discount rules (rule-based)
User story: As a customer, I want to apply a promo code at checkout so I pay the discounted price.
- If the code is valid and the cart total is at least $50, then the 10% discount applies to the cart subtotal before tax and shipping.
- If the code is valid but the cart total is below $50, then the discount is not applied and the message states the minimum spend.
- If the code has expired, then it is rejected with an "expired" message.
- If the customer already applied a code, then a second code replaces the first rather than stacking with it.
- If the cart changes after a code is applied, then eligibility is checked again immediately.
Rules like these are where ambiguity is most expensive. "Apply a discount" is a sentence. The five rules above are a specification.
Example 4: File upload (mixed)
User story: As a project manager, I want to upload documents to a task so my team can find them in one place.
- Accepted formats are PDF, DOCX, XLSX, PNG and JPG. Any other format is rejected with a message listing the allowed types.
- The maximum file size is 25 MB. A larger file is rejected before upload begins.
- Given an upload is in progress, when I lose my connection, then I see a failure message and can retry without re-selecting the file.
- Uploaded files appear on the task within 5 seconds, with the file name, size and uploader.
- Only members of the project can view or download the files.
The last line matters. It is a permission rule disguised as a small detail, and it is exactly the kind of thing that gets missed when criteria are left to memory.
Example 5: Email notifications (Given/When/Then)
User story: As a team lead, I want an email when a task assigned to me is overdue so I can follow up.
- Given a task is assigned to me and its due date has passed, when the daily check runs at 8:00 a.m. in my time zone, then I receive one email listing the overdue task.
- Given I have three overdue tasks, when the daily check runs, then I receive a single email listing all three, not three emails.
- Given I have turned off overdue notifications in settings, when the daily check runs, then I receive no email.
- Each email contains a link that opens the task directly.
Example 6: Mobile app, offline state (checklist)
User story: As a field technician, I want to view my job list without a connection so I can work in places with poor signal.
- Jobs synced in the last session remain visible when the device is offline.
- An "offline" banner is visible on every screen while there is no connection.
- Changes made offline are saved on the device and sent automatically when the connection returns.
- If the same job was edited elsewhere in the meantime, the technician is shown both versions and asked which to keep.
If your product runs on phones, pair criteria like these with a device-level checklist. Our mobile app testing checklist shows how to turn them into a quick smoke run across a device matrix.
What separates good criteria from weak ones
The examples above share a handful of traits. Use them as a review checklist before a story enters a sprint.
They describe outcomes, not implementation
Criteria should be written from the user's perspective and be outcome-driven, not implementation-driven. "The search uses an Elasticsearch index" tells engineers how to work and breaks the moment they choose a better tool. "Results appear in under 2 seconds" tells them what the user needs and leaves the solution to them.
A useful test: if a tester needs a debugger to verify a criterion, it is a technical requirement, not an acceptance criterion. Atlassian's guidance makes the same point: someone who knows nothing about the tech stack should be able to check it.
Every criterion maps to a test
Each criterion should map to at least one test, ideally at the cheapest level that can prove it: a unit test for data normalization, an end-to-end test for a user workflow. If you cannot describe the test before building starts, the criterion is probably too vague. This is a quick way to catch phrases like "fast", "intuitive" and "user-friendly" before they cost a sprint.
They are measurable where measurement is possible
Replace "the image looks good" with a condition like a minimum display resolution of 300x300 pixels, as one product guide suggests. You will not always have a number, but you almost always have a better word than "good".
They are independent and short
One criterion, one condition. "The user can log in and the session lasts 30 minutes and the error message is red" is three tests wearing one sentence. If a criterion fails, you want to know which one. A story with more than eight or ten criteria is usually two stories.
They cover the unhappy paths
Most weak criteria describe only success. Add the empty state, the invalid input, the timeout, the permission denied. In the login example, three of four criteria are about failure, because that is where the bugs live.
Weak versus strong, side by side
| Weak | Why it fails | Stronger |
|---|---|---|
| The page loads quickly | No threshold, untestable | The page is interactive within 2 seconds on broadband |
| The form is easy to use | Opinion | A first-time user completes the form in under 3 minutes in usability testing |
| Passwords are secure | Vague | Passwords must be at least 12 characters and are rejected if found in a list of known breached passwords |
| Use a modal for confirmation | Dictates implementation | The user must confirm before a delete is carried out |
| Errors are handled | No behavior defined | An invalid card number shows "Check your card number" under the field and keeps other entries intact |
Acceptance criteria vs. definition of done
Teams mix these up constantly, and the difference is simple. Acceptance criteria are conditions that a specific backlog item must meet to be accepted by a customer, user or another system. The definition of done is a shared checklist, covering things like functionality, performance, security and compliance, that applies to every increment.
Think of it this way:
- Acceptance criteria are unique to one story: "Overdue emails are sent once per day, not once per task."
- Definition of done is the same for every story: code reviewed, automated tests passing, no open critical defects, documentation updated, deployed to staging.
Atlassian's guide to the definition of done treats assigning acceptance criteria to user stories as a separate step, since criteria cover the feature while the DoD covers overall quality. A story is done only when it satisfies both. If the criteria pass but the code was never reviewed, it is not done. If the code is clean but the user cannot do what the story promised, it is not done either.
In practice, keep repeated items out of your criteria. If every story needs a security scan, put it in the definition of done once rather than copying it into forty tickets.
Who writes them, and when
The product owner or business analyst usually drafts criteria, but they should not write them alone. The strongest approach is a short conversation between the person who owns the requirement, a developer and a tester, held before the story is pulled into a sprint. Developers spot technical edge cases, testers spot the untestable phrasing, and the product owner spots the missing business rule. Fifteen minutes of that conversation tends to save days of rework.
For larger projects, criteria grow out of earlier analysis work. If your stories feel thin, the gap is often upstream. Techniques such as process mapping, interviews and prototyping, covered in our overview of business analysis techniques, give you the raw material for criteria that reflect real needs.
Bring security and quality into the criteria
Non-functional requirements are the ones teams forget, then discover late. Performance, accessibility and security can all be written as criteria. Security guidance from OWASP argues that security requirements are often best embedded in acceptance criteria for high-stakes features, so that security is a condition of done rather than an afterthought.
For a payment or account feature, that might look like:
- All inputs are validated on the server, and invalid requests are rejected with a generic error.
- Static code analysis reports no high-severity findings before release.
- Session tokens are invalidated when the user logs out.
If you want a fuller list of controls you can turn into testable statements, see our web app security checklist. To see how different test levels check different criteria, read our guide to QA testing types.
Our perspective
We build web and mobile products for clients across industries, and the pattern is consistent: projects rarely go wrong because the code is bad. They go wrong because two people pictured two different features and nobody wrote down the difference. Acceptance criteria are the cheapest place to find that out.
A few habits we rely on:
- Criteria come out of discovery, not after it. Business analysis and a discovery phase give us the user flows and business rules, so criteria are drafted from evidence rather than guesses.
- QA reads the criteria first. If our testers cannot describe a test for a line, we rewrite the line before development begins.
- We write the sad paths on purpose. Empty states, timeouts and permission errors get their own criteria every time.
- We keep the shared checklist separate. Security, review and regression standards live in the definition of done, so story criteria stay short and specific.
One caution from experience: do not treat criteria as a contract to be litigated. They work best as a shared picture of the outcome. When something new appears mid-sprint, change the criteria openly and agree on the change, rather than letting the scope drift in silence.
— Dmitry
When you want a team to do this with you
If you are planning a product and want criteria, test plans and delivery to line up from day one, our business analysis services turn requirements into stories with testable criteria, and our software testing and QA services verify them release after release. If you are still shaping the scope, a discovery phase is the natural place to start.
A repeatable process for your next story
- Start from the user story. Confirm who the user is and what outcome they want.
- List the happy path. What does success look like, step by step?
- Add the failure paths. Invalid input, missing data, no connection, no permission.
- Choose the format. Flow: Given/When/Then. Simple UI: checklist. Business logic: rules.
- Add numbers. Limits, times, sizes, counts, thresholds.
- Remove implementation detail. Rewrite anything that says how, not what.
- Run the test check. Can you describe a test for each line? If not, rewrite it.
- Review together. Product owner, developer and tester, before the sprint starts.
- Move shared items to the definition of done. Keep story criteria unique to the story.
When a release is close, the same criteria feed your regression suite. Our regression testing plan shows how to keep that suite fast enough to be useful.
FAQ
What is a good example of acceptance criteria?
For a password reset story: "Given I enter a registered email, when I request a reset, then I receive a link that expires after 60 minutes." It is specific, observable and testable, and it names a number. A second criterion should cover the unregistered email case so the behavior is defined for both paths.
How many acceptance criteria should a user story have?
There is no fixed number, but most well-sized stories need between three and eight. If you are past ten, the story probably contains more than one piece of value and should be split. If you have only one, check that you have covered the failure paths.
Can acceptance criteria change during a sprint?
They can, but only with the agreement of the product owner and the team, and the change should be written down. Quiet changes cause the scope creep that criteria exist to prevent. If a change is large, move it to a new story and finish the original.
Do acceptance criteria replace test cases?
No. Criteria say what must be true, while test cases describe the exact steps and data that prove it. One criterion often produces several test cases, for example valid, boundary and invalid inputs. Each criterion should map to at least one test.
Sources
- Acceptance criteria, Tech Lead Handbook
- 19 Acceptance Criteria Examples for Product, ProdPad
- What is Acceptance Criteria? Atlassian
- Developing and Using Acceptance Criteria Guidance, Ohio OBM
- What Is the Difference Between the Definition of Done and Acceptance Criteria? Scrum.org
- What is the Definition of Done (DoD) in Agile? Atlassian
- Proactive Risk Mitigation within the Software Development Lifecycle, OWASP