Ambiguity is the enemy of development.
1Defining the Edge Cases
The main flow is easy. Great ACs define what happens when things go wrong. What if the user enters an invalid email? What if the network is down? ACs should cover these 'Unhappy Paths'.
2Shared Understanding
The process of writing ACs with your team is more important than the document itself. It's during this time that you uncover technical constraints or design inconsistencies.
3Pass/Fail for QA
The ACs are the foundation of the QA testing plan. If a feature passes all ACs, it is 'Done' from the Product perspective, regardless of how many other ideas people have.
4Step-by-Step Breakdown
Acceptance Criteria (AC) are the conditions that a product must meet to be accepted by a user, customer, or other stakeholder.
The purpose of AC is to define the boundaries of a story, prevent scope creep, and provide a clear 'Pass/Fail' checklist for testing.
Scenario Format: 'GIVEN [context], WHEN [action], THEN [expected outcome]'. This BDD (Behavior Driven Development) style is highly effective.
A well-written Acceptance Criterion should be:
- →Vague enough to allow for changes later
- →Binary (either the product does it or it doesn't)
- →Written in pseudo-code
- →At least 500 words long
Which of these is a correct Gherkin (Given/When/Then) scenario for a login feature?
- →As a user I want to login
- →GIVEN I am on the login page, WHEN I enter valid credentials, THEN I should be redirected to my dashboard
- →The login page should load in under 2 seconds
- →Users can reset their password if they forget it
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Write Accessibility Into the Criteria Itself
If 'keyboard operable' or 'screen reader announces the error' isn't listed as an acceptance criterion, it's easy for a feature to ship without it — QA tests against the AC list, so anything missing from that list is unlikely to get tested.
GIVEN a user is navigating the form with a keyboard only
WHEN they reach the submit button
THEN it must be focusable and reachable via Tab, with a visible focus outlineSEO Implications
- 1
AC Prevents SEO Regressions From Slipping Through
If a redesign's acceptance criteria don't explicitly state that the canonical URL, meta description, and heading structure must remain unchanged, a developer has no signal that those details matter, and a page can lose its search ranking silently.
Best Practices
Write AC Before Development Starts, Not After
AC written after a feature is built tends to just describe whatever was shipped, defeating its purpose as a spec. Write it during backlog refinement so developers know the target before they start coding.
One Criterion, One Testable Claim
Avoid bundling multiple checks into a single AC line with 'and'. If a criterion covers three things and one fails, it's unclear whether the story fails entirely or partially — split it into separate, independently testable lines.
Frequent Bugs
AC describes only the ideal input, so a feature ships that crashes or behaves undefined on empty input, extremely long strings, or a slow or failed network — no one tested it because it wasn't written down.
For every story, explicitly write at least one 'unhappy path' criterion (empty state, error state, boundary values) alongside the happy path, so QA has something concrete to check against.
Real-World Examples
Password Reset Acceptance Criteria
A team is building a 'forgot password' flow and needs AC precise enough that QA, design, and engineering all agree on what 'done' means.
GIVEN a user enters an email that isn't registered
WHEN they submit the forgot-password form
THEN show a generic "if this email exists, a reset link was sent" message (do not reveal whether the account exists)
GIVEN a reset link is older than 1 hour
WHEN the user clicks it
THEN show "This link has expired" and offer to resend