•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
Key takeaways
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.
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:
A testable criterion has three properties:
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.
Most teams use one of two formats. Pick one per story, don't mix them.
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.
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.
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.
Web AC often skip device, platform, and network context. Mobile can't.
A mobile criterion is incomplete without answering:
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.
Story: As a user, I want to add items to my cart so I can buy them.
Bad AC:
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.
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.
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.
Acceptance criteria are testable conditions a user story must meet to be accepted by product owner as complete.
The user story states goal. Acceptance criteria define testable conditions that prove goal is met.
Use Given When Then for multi step flows. Use rule based checklists for simple constraints or input validation rules.
Most stories need 3 to 7 criteria. More than 10 usually means story is too large and should be split.
The product owner drafts them. QA and developers review them before sprint planning to confirm testability and feasibility.
Yes. Each failure path (invalid input, network error, denied permission) needs its own criterion or test coverage will be incomplete.
©Drizz 2026 • All Rights Reserved
