How many times have you delivered a feature only to hear: “That’s not what I expected”?
That moment is usually a sign that your acceptance criteria weren’t clear enough.
Writing strong acceptance criteria is one of the simplest, most powerful ways to avoid scope creep, miscommunication, and rework. It defines the finish line—and when done right, everyone from developers to testers to stakeholders knows exactly what “done” looks like.
What Are Acceptance Criteria?
Acceptance criteria are the conditions that a product or feature must meet to be considered complete and acceptable by the business. They’re written in plain language and linked to user stories, features, or requirements.
They answer:
What does success look like?
What should (or shouldn’t) happen?
How will we verify that it works?
Why Vague Acceptance Criteria Cause Problems
Let’s say your criteria is:
“User can submit a form.”
Seems clear? Not really. Questions arise:
What fields are required?
What happens on submission?
Are there validation rules?
Does the user get a confirmation?
Without specifics, developers guess, testers improvise, and stakeholders get surprises. That leads to frustration and rework.
The Goal: Clear, Testable, Unambiguous
Good acceptance criteria:
Are specific about behaviors
Are testable and binary (pass/fail)
Use the user’s language, not just technical terms
Cover both positive and negative scenarios
Avoid subjectivity (“easy to use,” “looks good”)
How to Write Great Acceptance Criteria
Here are three popular and effective formats:
1. Given / When / Then (Gherkin Style)
This format comes from Behavior-Driven Development (BDD) and creates clear scenarios:
Given some context
When an action is taken
Then an outcome occurs
Example:
User Story: As a customer, I want to reset my password so I can regain access.
Acceptance Criteria:
Given the user is on the login screen
When they click “Forgot Password” and enter their email
Then a reset link is sent to that email address
And they see a confirmation message
2. Checklist Format
Simple bullet points with conditions to meet.
Example:
User must enter a valid email format (e.g., name@example.com)
Password must be at least 8 characters
“Submit” button is disabled unless all fields are valid
Upon submission, a confirmation message appears
3. Rules-Based Format
Good for features that follow business logic or policies.
Example:
Orders over $500 require manager approval
Discounts over 20% cannot be applied without a promo code
Users under 18 cannot complete registration
Include These Key Elements
Here’s a quick checklist to improve your criteria:
| Element | Why It Matters |
|---|---|
| Preconditions | Define the starting state clearly |
| User actions | Clarify what the user does |
| System responses | Define what the system must do |
| Data conditions | Include required input, limits, or formats |
| Edge cases | Consider what happens when things go wrong |
| Non-functional needs | Speed, error messages, accessibility (if critical) |
Common Mistakes to Avoid
“Should work as expected” – too vague
“Form should be user-friendly” – subjective
Leaving out error handling – misses real-world use
Duplicating requirements – clutters the story
Changing criteria mid-sprint – causes churn
Real-World Example: Weak vs. Strong Criteria
Weak:
“User can download the report.”
Too vague. What report? How? In what format?
Strong:
Given the user has selected a date range
When they click “Download Report”
Then a PDF of the report for that range downloads
And the file is named in the format: report_YYYYMMDD.pdf
Tips for Better Acceptance Criteria
Write criteria before development starts: It saves time and money.
Collaborate with stakeholders: Product owners, testers, and devs should all review.
Make it binary: Pass/fail. No maybes.
Review during grooming or backlog refinement.
Store them in your tools: Add to Jira, Azure DevOps, or whatever your team uses.
Acceptance Criteria Writing Checklist
- Clear user context and preconditions
- Describes both action and outcome
- Includes edge/error cases
- Uses consistent structure (Given/When/Then or bullets)
- No vague terms (“easy,” “fast,” “intuitive”)
- Reviewed and agreed upon by team
- Tied directly to the story or requirement
Final Takeaway
Strong acceptance criteria are like blueprints for success. They prevent misunderstandings, align teams, and ensure quality delivery.
Don’t leave it up to interpretation. Define what “done” means—clearly, completely, and collaboratively.
“If it’s not testable, it’s not finished.”
Start writing clearer acceptance criteria today—and experience fewer surprises tomorrow.