What is acceptance criteria?
Acceptance criteria are concrete, measurable conditions that must be met for a feature, user story, or deliverable to be considered complete and accepted. They define what done means in testable terms that both the team and the client can verify.
Why acceptance criteria matter?
Without clear acceptance criteria you get:
- disputes about whether work is complete
- avoidable rework and longer delivery
- scope creep from small unplanned asks
- payment delays and sign off friction
- weaker trust between team and client
Good vs. bad acceptance criteria
❌ Bad (too vague)
- “User login should work well”
- “The design should be modern”
- “Performance should be good”
- “Error handling should be implemented”
✅ Good (specific and testable)
- “Users can log in with email and password or Google OAuth and see a success message”
- “UI matches approved Figma v2.3 with up to 5 px deviation”
- “First contentful paint under 2 seconds on 4G”
- “Invalid inputs show inline error messages within 100 ms”
Format: given-when-then
A popular format for acceptance criteria:
Given the initial context
When the user takes an action
Then the expected outcome happens
Example: user registration
Given I am a new user on the registration page
When I enter a valid email, a password with 8+ characters and 1 number, and click "Sign up"
Then:
- my account is created
- I receive a verification email within 1 minute
- I am redirected to the verification pending page
- a success message appears, "Account created. Please check your email."
How to write effective acceptance criteria?
1. Be specific
Not, “User can search”
But, “User can search products by name, category, or SKU, with results in under 200 ms”
2. Make it testable
Each criterion should be binary. Pass or fail, yes or no.
3. Include edge cases
- invalid and empty inputs
- empty states and limits
- error messages and recovery
- timeouts and retries
4. Focus on “what,” not “how”
Not, “Use Elasticsearch with fuzzy matching”
But, “Search returns relevant results with minor typos of 1 to 2 characters”
5. Be complete
Cover happy path, error scenarios, edge cases, performance, security, and accessibility where relevant.
Real-world example: e-commerce checkout
Feature: Shopping cart checkout
Acceptance criteria:
✅ User can proceed to checkout only when the cart has at least one item
✅ Checkout form includes shipping address, billing address, and payment method
✅ User can save addresses for future use
✅ Shipping cost is calculated automatically based on destination
✅ Promo codes validate in under 500 ms
✅ Invalid promo codes show, “Invalid or expired promo code”
✅ Payment uses Stripe and meets PCI requirements
✅ Successful orders show a confirmation page with an order number
✅ Confirmation email is sent within 2 minutes
✅ Failed payments show a clear error with next steps
✅ Cart persists if the user returns within 7 days
✅ Order appears in the user history immediately
Acceptance criteria in different contexts
For entire projects
High level delivery criteria, for example:
- all pages load under 3 seconds
- works on Chrome, Firefox, and Safari, latest two versions
- responsive from 320 px to 1920 px
- passes WCAG 2.1 AA checks
For user stories
Define when the story is complete from a user point of view. Use clear, observable outcomes.
For bug fixes
Define how you confirm the fix:
- the original error no longer occurs on the specified action
- no related console errors appear
- affected users can complete the task end to end
Acceptance criteria vs. definition of done
Acceptance criteria are specific to one feature or story.
Definition of done is a shared checklist that applies to all work.
Example definition of done
- code reviewed by a peer
- unit tests written and passing
- acceptance criteria met
- documentation updated
- deployed to staging
- client approved
Common mistakes
1. Too many criteria
If a story has more than 15 criteria, split it into smaller stories to reduce risk and speed up testing.
2. Mixing implementation details
Describe outcomes, not solution internals.
3. Missing negative cases
Always include what should not happen and how the UI responds.
4. Ignoring non-functional requirements
Include performance, security, accessibility, and cross browser rules when they matter.
5. No client input
Agree criteria with the client before work starts. Confirm again during review.
Who writes acceptance criteria?
Collaborative approach
- product owner or client adds business intent
- developers validate feasibility
- designers ensure UX consistency
- QA turns criteria into test cases
Everyone reviews and agrees before development begins.
Using acceptance criteria for estimates
Clear criteria make estimates faster and more accurate:
Feature: User profile
Acceptance criteria: 8 items
Estimate:
- backend API: 12 hours
- frontend: 16 hours
- testing: 6 hours
Total: 34 hours
Estimate each criterion or small group to improve precision.
Testing against acceptance criteria
QA can use criteria directly as test cases:
Test case #1
Criterion: "User can upload a profile photo up to 5 MB, JPG or PNG"
Steps:
1. Go to profile settings
2. Click "Upload photo"
3. Select a valid JPG under 5 MB
Expected: photo uploads and preview appears
Negative:
1. Try to upload an 8 MB file
Expected: error "File too large, max 5 MB"
FAQ
What are acceptance criteria in software projects?
They are measurable, testable conditions that define when a task or feature is complete and acceptable to a client.
How do I write good acceptance criteria?
Use simple language, keep them specific and testable, follow the given-when-then format, and always agree them with the client.
What’s the difference between acceptance criteria and definition of done?
Acceptance criteria apply to a single story or feature, while definition of done is a general checklist for all work across the team.
How many acceptance criteria should a story have?
Usually between three and eight. If there are more, break the story into smaller parts.