Key takeaways
- Acceptance criteria are testable conditions a feature must meet before it ships, written for QA verification, not engineering implementation.
- The most common failure is vague language ("loads fast", "works well") that passes review but can't be turned into a pass/fail test case.
- Each criterion should be binary, specific, and map one-to-one to a test case QA can write and automate.
Acceptance criteria are conditions a feature must satisfy to be considered done. They're written from user's perspective and must be testable, so QA can run them and get a clear pass or fail.
If a criterion needs human judgment to evaluate ("dashboard feels responsive"), it isn't acceptance criteria. It's an opinion. QA can't write a test case against it, and team will argue about whether feature is done.
The job of acceptance criteria is to make "done" objective. According to Atlassian's guide on acceptance criteria, well-written conditions align engineering, QA, and product on a measurable standard before code ships.
What are acceptance criteria, exactly
Short definition of acceptance criteria: specific, testable conditions a user story must satisfy to be accepted by product owner.
They sit between user story (what user wants) and test case (how QA verifies it). The user story states intent. Acceptance criteria translate that intent into behaviors a tester can observe.
Three things they're not:
- Not requirements. Requirements describe what to build. Criteria of acceptance describe how to verify it works.
- Not technical specs. "Data is cached in Redis" is an implementation choice. AC describe what user sees.
- Not definition of done. DoD is a team checklist (code reviewed, deployed). AC are unique to each story.
What testable acceptance criteria look like
A testable criterion has three properties:
- Binary outcome. It either passes or fails. No subjective scoring.
- Specific inputs and outputs. "When user taps X, system shows Y."
- Independently verifiable. You can test it without running every other criterion first.
Compare these two:
Not testable: The login screen should be fast and easy to use.
Testable: When user enters a valid email and password and taps "Sign in", home screen loads within 3 seconds on a 4G connection.
The second one tells QA exactly what to do, what to measure, and when test passes. The first one will spawn three meetings.
Two formats that work (with acceptance criteria examples)
Most teams use one of two formats. Pick one per story, don't mix them.
Given When Then (scenario based)
Borrowed from behavior-driven development. Best for flows with state and multiple steps. Martin Fowler's writeup on Given-When-Then covers underlying logic.
Acceptance criteria example for a checkout flow:
Given a user is logged in with items in their cart
When the user taps "Proceed to checkout"
Then the checkout screen loads
And the cart total displays
And the user's saved address is pre-filled
Each line maps to a verification step. QA writes one test case per scenario.
Rule based (checklist)
Best for simple features or input constraints. Each line is one rule.
- Email field rejects inputs without "@" symbol
- Password field requires minimum 8 characters
- "Sign in" button disables until both fields have valid input
- Failed login displays "Invalid email or password" within 2 seconds
Rule based is faster to write but harder to use for multi-step flows. Use Given-When-Then for journeys, rules for constraints.
Why most user story acceptance criteria fail QA
Posts about acceptance criteria usually stop at "make it testable" without showing where teams go wrong. Here are failures we see most often:
Vague modifiers. Words like "fast", "smooth", "intuitive", "appropriate" have no test case. Replace them with numbers. "Fast" becomes "under 2 seconds". "Appropriate error" becomes exact error string.
Implementation leaks. "Data is cached in Redis with a 5 minute TTL" is a technical decision, not a criterion. AC describe what user sees, not how code works.
Hidden assumptions. "User can pay with Apple Pay" assumes device has Apple Pay set up, network is online, and merchant ID is configured. List preconditions or test will fail for wrong reason.
Missing negative paths. Teams write happy paths and forget what happens when things break. What does user see when payment fails? When network drops mid-checkout? When session expires? Each one is a separate criterion.
One criterion doing five things. "User can sign up, log in, reset password, and update profile" is four user stories, not one criterion. Split it.
A study by Project Management Institute found that 56% of project budget put at risk is due to ineffective communication, and unclear requirements sit at top of that list.
Mobile acceptance criteria need extra detail
Web AC often skip device, platform, and network context. Mobile can't.
A mobile criterion is incomplete without answering:
- Platform: iOS, Android, or both? Behavior often differs.
- Device class: Phone, tablet, foldable? Layout changes.
- Network: Online, offline, slow 3G? State handling matters.
- Permissions: What happens if location, camera, or notifications are denied?
- Interrupts: Incoming call, low battery, app backgrounded mid-flow.
A good mobile criterion looks like this:
Given the user is on the product detail screen
And location permission is denied
When the user taps "Find in store"
Then the app shows an inline message: "Enable location to see nearby stores"
And a "Open Settings" button is visible
That's testable on iOS, on Android, with permission denied, in one test case. Compare it to "app handles location gracefully", which means nothing.
Bad vs good: a full acceptance criteria example
Story: As a user, I want to add items to my cart so I can buy them.
Bad AC:
- User can add items to cart
- Cart works correctly
- Errors are handled
Good AC:
Given the user is on a product detail screen
When the user taps "Add to cart"
Then the cart icon badge increments by 1
And a toast appears: "Added to cart"
And the toast disappears after 3 seconds
Given the user has 99 of the same item in cart
When the user taps "Add to cart" again
Then the quantity stays at 99
And a toast appears: "Maximum quantity reached"
Given the user is offline
When the user taps "Add to cart"
Then an inline message appears: "Connect to add items"
And the cart badge does not change
The bad version produces three meetings and a bug ticket. The good version produces three test cases QA can execute today.
From acceptance criteria to executable tests
Well-written AC are one step away from automated test cases. The criterion lines should translate almost directly to test commands.
This is where most QA workflows stall. The criterion says "tap Add to cart", but test framework needs findElement(By.id("com.app:id/add_btn_v2_new")). Every UI rename breaks locator. The AC didn't change. The test broke anyway. This is hidden cost of flaky selector-based tests most teams underestimate.
Drizz closes that gap. Tests are written in same language as criterion:
Tap "Add to cart"
Validate "Added to cart" is visible
Tap "Add to cart"
Validate cart badge displays "2"
Vision AI finds button by what it looks like, way a user does. When dev team renames resource ID or restyles button, test still passes because label is still "Add to cart". The AC becomes test, line for line.
For teams using Drizz, workflow looks like this: a PM writes AC in Given-When-Then. QA pastes When and Then lines into Drizz almost verbatim, replacing "user taps" with Tap and "user sees" with Validate is visible. The result is a runnable test in same review cycle as story, with no selector maintenance afterward.
Acceptance criteria in Scrum: who writes them and when
Product owners draft. QA and engineering review before story enters sprint planning.
If QA sees criterion for first time during sprint planning, two things happen. Either team commits to something that can't be tested, or QA flags it and story gets pushed.
The fix is involving QA during backlog refinement, one or two sprints ahead. QA's only question is: "Can I write a test case for this today?" If answer is no, criterion goes back.
In Scrum specifically, acceptance criteria are written during backlog refinement and finalized at sprint planning. Once a sprint starts, criteria shouldn't change unless change doesn't block ongoing work. Mid-sprint rewrites usually mean story was undersized and should be re-estimated.
This is also where Definition of Done becomes a separate concern. AC apply to one story. DoD applies to all stories. Don't put DoD items inside AC, you'll write same five lines on every ticket.
FAQ
What is meaning of acceptance criteria in agile?
Acceptance criteria are testable conditions a user story must meet to be accepted by product owner as complete.
What's difference between acceptance criteria and a user story?
The user story states goal. Acceptance criteria define testable conditions that prove goal is met.
What format should I use for acceptance criteria?
Use Given When Then for multi step flows. Use rule based checklists for simple constraints or input validation rules.
How many acceptance criteria per user story?
Most stories need 3 to 7 criteria. More than 10 usually means story is too large and should be split.
Who is responsible for writing acceptance criteria?
The product owner drafts them. QA and developers review them before sprint planning to confirm testability and feasibility.
Should acceptance criteria include negative scenarios?
Yes. Each failure path (invalid input, network error, denied permission) needs its own criterion or test coverage will be incomplete.
