Summarize this article with:
A feature that “works” but misses what the stakeholder actually wanted is still a failed delivery. That is exactly what happens when teams skip acceptance criteria in software projects.
Acceptance criteria defines the specific conditions a user story must meet before anyone can call it done. It is the line between “we built something” and “we built the right thing.”
This article covers what acceptance criteria is, how it connects to user stories and Agile workflows, the main formats for writing it, common mistakes that break it, and real examples from login features to e-commerce search. You will also find practical guidance on preventing scope creep and running acceptance testing against your criteria.
What Is Acceptance Criteria
Acceptance criteria is a set of predefined conditions that a software feature must satisfy before stakeholders consider it complete. Each condition describes a specific, testable behavior from the end user’s perspective.
Think of it as a pass/fail checklist attached to every user story in your product backlog.
The product owner, developers, and QA engineers all reference these conditions throughout the sprint. Without them, “done” means something different to every person on the team. That kills velocity fast.
Acceptance criteria sits inside the Agile development process as a bridge between what the business wants and what the development team builds. It belongs to the software requirement specification layer of your project, but at a much more granular level.
Every criterion follows one rule: it must be independently testable with a clear yes or no outcome.
A user story says what the user wants. Acceptance criteria says when that want is actually met. The story provides direction. The criteria provides proof.
Teams working in Scrum, Kanban, Extreme Programming, or any iterative development approach use acceptance criteria to keep scope tight and expectations aligned. It does not matter if you are building a web app, a mobile application, or an internal tool. The principle stays the same.
How Do Acceptance Criteria Differ from the Definition of Done
These two terms get mixed up constantly. They are not the same thing.
Definition of Done is a universal checklist that applies to every single work item your team delivers. It covers things like code review completion, passing unit tests, updated documentation, and deployment to a staging environment.
Acceptance criteria is specific to one user story. It describes the unique behavior and conditions that particular feature must demonstrate.
Here is the simplest way to separate them:
- Definition of Done answers: “Did we follow our standard process?”
- Acceptance criteria answers: “Does this feature do what the user actually needs?”
A login feature might have acceptance criteria like “the system locks the account after 5 failed attempts.” Meanwhile, the Definition of Done says “all code passed the code review process and regression testing is complete.”
Both must be satisfied before a user story moves to “done.” One without the other leaves gaps.
Why Are Acceptance Criteria Written Before Development Starts
Writing acceptance criteria after development begins is like building a house and then deciding where the doors go. It creates rework, confusion, and missed deadlines.
Criteria gets defined during sprint planning or backlog refinement meetings. The product owner brings the user stories. The team discusses what “complete” looks like for each one. Then they write it down.
This timing matters for three reasons:
- Developers know exactly what to build before writing a single line of code
- Testers can start preparing test cases immediately based on the functional and non-functional requirements
- Scope creep gets blocked because anything not in the criteria does not belong in that sprint
Took me a while to fully appreciate this. Early in my career, I watched teams skip this step and just “figure it out as they go.” The result was always the same: features that technically worked but missed what the stakeholder actually wanted.
Late-stage requirement changes cost roughly 6x more than changes made during the planning phase, according to the Project Management Institute. Writing criteria early is not extra work. It is the work that saves all the other work.
Teams that follow a proper software development process treat acceptance criteria as a required input before any sprint begins. Not optional. Not “nice to have.”
Who Writes Acceptance Criteria in a Software Team
There is no single owner. Acceptance criteria is a team effort, and honestly, it works better that way.
The product owner typically starts the conversation. They understand what the business needs and what the end user expects. But they do not write criteria alone.
Developers add technical feasibility. They catch edge cases the product owner might miss. A software tester looks at it from a validation angle, asking “how do I prove this works?” and “what happens when it breaks?”
The business analyst, if your team has one, often drafts the initial criteria as part of the project’s technical documentation. Then the whole team reviews it during backlog refinement.
Here is how different roles contribute:
- Product Owner / Product Manager – defines what the user needs and validates final criteria
- Developers – flag technical constraints and missing edge cases
- QA Engineers – confirm each criterion is testable and measurable
- Business Analyst – structures criteria within broader requirements engineering documentation
The collaborative approach matters because a product owner writing criteria in isolation almost always produces gaps. They know the “what” but not always the “what could go wrong.”
What Are the Main Formats for Writing Acceptance Criteria
Three formats dominate the industry. Each one fits different situations, and most teams end up using a mix depending on the complexity of the feature.
How Does the Given-When-Then Format Work
This comes from behavior-driven development (BDD) and uses Gherkin syntax. It structures each criterion as a scenario with three parts:
- Given – the precondition or initial state
- When – the action the user takes
- Then – the expected result
Real example for a password reset feature:
Given a registered user is on the login page, When they click “Forgot Password” and enter their registered email, Then the system sends a password reset link to that email within 60 seconds.
This format works best for complex features with multiple user scenarios. It reads like plain English, which makes it accessible to non-technical stakeholders. Teams using Cucumber or similar testing tools can even convert these directly into automated test scripts.
What Is the Rule-Based Format for Acceptance Criteria
Sometimes you do not need a full scenario. You just need a clear list of rules the system must follow.
Rule-based criteria works well for straightforward system constraints and simple validation requirements. Example for a registration form:
- The password field requires a minimum of 8 characters
- The password must contain at least one uppercase letter and one number
- The email field rejects duplicate addresses already in the database
- The system displays a confirmation message after successful registration
No “Given-When-Then” structure needed. Just clear, testable rules. This is the most common format across Agile teams because it is fast to write and fast to validate.
When Should You Use the Verification-Based Format
The verification-based (or use-case) format breaks the interaction into numbered steps with expected system responses. It fits process-heavy workflows where order matters.
Example for an order checkout:
- The user adds items to the cart and clicks “Checkout”
- The system displays the order summary with item names, quantities, and total price
- The user selects a payment method and enters payment details
- The system validates payment information and processes the transaction
- The system displays an order confirmation with a unique order number
This format mirrors actual user workflows step by step. It is particularly useful during acceptance testing because testers can follow the exact sequence and verify each response matches the expected outcome.
Most teams pick one primary format and pull from the others when the situation calls for it. There is no single right answer here, just what makes the criteria clearest for your specific feature and your specific team.
What Makes Acceptance Criteria Testable
If you cannot verify it with a clear pass or fail result, it is not acceptance criteria. It is a wish.
Testable criteria have three properties: they are specific, measurable, and independent of each other. Each one gets validated on its own without relying on another criterion to pass first.
Here is where most teams get it wrong. Compare these two:
- Vague: “The page should load quickly”
- Testable: “The search results page loads within 2 seconds on a 4G connection”
The first version means something different to every person who reads it. The second version gives your quality assurance team a concrete number to test against.
Every criterion needs a binary outcome. Did the system send the confirmation email, yes or no? Did the error message display when the user left the field blank, yes or no? If the answer requires interpretation, rewrite the criterion.
Teams running test-driven development often convert acceptance criteria directly into automated test cases before writing any feature code. The criteria becomes the test. That is the level of precision you should aim for.
What Are Common Mistakes When Writing Acceptance Criteria
Bad criteria causes more rework than bad code. I have seen entire sprints derailed because someone wrote acceptance criteria that looked fine on paper but fell apart during validation.
How Does Ambiguity Break Acceptance Criteria
Words like “appropriate,” “user-friendly,” and “fast” are subjective. They create different expectations for the product owner, the developer, and the tester. Every criterion needs a concrete, measurable condition that leaves zero room for interpretation.
What Happens When Acceptance Criteria Are Too Broad
Broad criteria invites scope creep. “The user can manage their profile” could mean 5 features or 50. Break it down: “The user can update their display name,” “The user can upload a profile photo under 5MB,” “The user can change their email after re-authentication.”
Why Should Acceptance Criteria Avoid Technical Implementation Details
Criteria defines what the system does, not how the codebase accomplishes it. Writing “use a PostgreSQL query to fetch results” locks developers into a specific approach. Write “the system returns matching results within 2 seconds” instead, and let the team decide the implementation.
How Do Acceptance Criteria Connect to User Stories
A user story without acceptance criteria is an idea. A user story with acceptance criteria is a deliverable.
The story captures intent. The criteria captures proof. They always exist together in your product backlog.
Real example:
User Story: “As a customer, I want to reset my password so I can regain access to my account.”
Acceptance Criteria:
- A “Forgot Password” link is visible on the login page
- The system sends a reset link to the registered email within 60 seconds
- The reset link expires after 24 hours
- The new password must meet the same validation rules as the original (minimum 8 characters, one uppercase, one number)
- The system displays a success message after the password is changed
Notice how each criterion is independently testable. A test plan can be built directly from this list.
During sprint planning, the team estimates effort based on the complexity of these criteria, not the story alone. More criteria usually means more work, which means more accurate task estimation and sprint velocity calculations.
What Is an Example of Acceptance Criteria for a Login Feature
User Story: “As a registered user, I want to log into my account so I can access my dashboard.”
Given-When-Then format:
Scenario 1: Successful login Given the user is on the login page, When they enter a valid email and password and click “Log In”, Then the system redirects them to the dashboard within 3 seconds.
Scenario 2: Wrong password Given the user is on the login page, When they enter an incorrect password, Then the system displays “Invalid email or password” without specifying which field is wrong.
Scenario 3: Account lockout Given the user has entered an incorrect password 5 times, When they attempt a 6th login, Then the system locks the account for 30 minutes and sends a notification email.
Rule-based format for the same feature:
- The login form requires both email and password fields to be filled
- Empty field submissions trigger inline validation messages
- The “Remember Me” checkbox persists the session for 30 days
- The system logs all failed login attempts for security audit purposes
- Password input is masked by default with a toggle to show/hide
Two formats, same feature. The Given-When-Then version works better for scenario-based acceptance testing. The rule-based version is faster to scan during the testing lifecycle.
What Is an Example of Acceptance Criteria for an E-Commerce Search Feature
User Story: “As a shopper, I want to search for products by name so I can quickly find what I need.”
Acceptance criteria:
- The search bar is visible on every page of the application, positioned in the header
- The search function returns results for exact and partial matches (minimum 3 characters)
- Auto-suggest displays up to 5 product name suggestions as the user types
- Search results load within 2 seconds on a standard broadband connection
- Each result displays the product name, image (minimum 300×300 pixels), price, and average rating
- Results support pagination with a maximum of 20 items per page
- Users can filter results by category, price range, and brand
- A “No results found” message displays when the query returns zero matches, with suggested alternatives
This covers the happy path, edge cases, performance expectations, and UI/UX requirements in a single list. A front-end developer knows exactly what to build. A tester knows exactly what to check.
Notice the measurable specifics: 2 seconds, 300×300 pixels, 20 items per page, 3-character minimum. No guesswork.
How Do Acceptance Criteria Prevent Scope Creep in Agile Projects
Scope creep happens when new requirements sneak into a sprint that were never agreed upon. Acceptance criteria acts as a written contract against that.
If a stakeholder asks for an extra filter option mid-sprint, the team checks the criteria. Is it listed? No? Then it goes into the next sprint’s backlog. Simple.
This is not about being rigid. It is about protecting the team’s capacity and keeping the development plan on track.
Teams that follow a structured project management framework use acceptance criteria as the single source of truth for what belongs in a sprint. When a feature passes all its criteria, it is done. Nothing gets added after the fact without going through proper change request management.
The criteria also helps during sprint review meetings. The product owner validates each criterion one by one. Either it passes or it does not. There is no “well, it kind of works.” That binary clarity is what keeps projects from ballooning.
How Are Acceptance Criteria Used During Acceptance Testing
Each acceptance criterion becomes a test case. That is the direct relationship.
During user acceptance testing (UAT), stakeholders or designated testers walk through every criterion and mark it as pass or fail. If all criteria pass, the feature ships. If any fail, it goes back to development with a specific, documented reason.
The process typically follows this path:
- Developers build the feature against the defined criteria
- QA runs unit tests and integration tests mapped to each criterion
- The feature moves to a staging or pre-production environment
- The product owner or end users perform UAT against the original criteria
- Pass/fail results get documented for each individual criterion
Teams practicing continuous integration often automate parts of this. Acceptance criteria written in Given-When-Then format can be converted into automated test scripts using tools like Cucumber or Selenium.
The criteria you wrote before the sprint started is now the exact checklist your team uses to confirm the feature is ready for deployment. That loop, from planning to testing, is what makes acceptance criteria so effective across the entire development lifecycle.
What Tools Support Acceptance Criteria Management
The tool matters less than the discipline. But the right tool makes it easier for everyone to stay aligned across sprints.
How Does Jira Handle Acceptance Criteria
Jira does not have a dedicated acceptance criteria field out of the box. Most teams add a custom field (paragraph type) to their issue screens, or they write criteria directly in the user story description. Marketplace apps like Issue Checklist Pro add workflow validation so issues cannot transition to “Done” until every criterion is checked off.
What Other Project Management Tools Work for Acceptance Criteria
Azure DevOps supports acceptance criteria through its work item fields with built-in test case linking. Trello handles it with checklist cards, though it is more lightweight. Asana and Monday.com allow custom fields and task dependencies that map well to criteria tracking. For teams that need direct traceability between criteria and test execution, TestRail connects test cases to specific acceptance conditions with detailed reporting.
What Are Best Practices for Writing Clear Acceptance Criteria
After years of watching teams get this wrong (and getting it wrong myself), here is what actually works:
- Use plain language. If a non-technical stakeholder cannot understand the criterion, rewrite it.
- One condition per criterion. Compound criteria with “and” or “also” should be split into separate items.
- Write from the user’s perspective. “The user sees a confirmation message” beats “the system triggers the confirmation modal component.”
- Make every criterion independently testable. Each one gets its own pass/fail result.
- Avoid negation when possible. “The system displays an error for invalid emails” is clearer than “The system should not accept invalid emails.”
- Keep sentences short. Fewer conjunctions, fewer misunderstandings.
- Include edge cases. What happens with empty fields, special characters, slow connections, expired sessions?
- Define criteria collaboratively. Product owner starts, developers and testers refine. No one writes criteria alone.
One more thing that most guides skip: revisit your criteria. If you discover new edge cases during development, update the acceptance criteria and communicate the change. Treating criteria as fixed after sprint planning creates blind spots.
Teams following established best practices review acceptance criteria at three points: during backlog refinement, at sprint planning, and again during the sprint review. That rhythm catches problems early, when they are cheap to fix.
And look, perfect acceptance criteria does not exist. Your mileage will vary based on your team’s maturity, the complexity of your software system, and how well your stakeholders communicate their needs. But consistently applying these practices gets you closer to criteria that actually prevents rework instead of causing it.
FAQ on What Is Acceptance Criteria In Software Projects
What is acceptance criteria in simple terms?
Acceptance criteria is a set of conditions a feature must meet before stakeholders approve it as complete. Each condition is testable with a clear pass or fail result. It applies to individual user stories within Agile sprints.
Who is responsible for writing acceptance criteria?
The product owner typically leads, but developers and QA engineers contribute during backlog refinement. Business analysts may draft initial criteria. The best results come from cross-functional collaboration, not a single person writing in isolation.
What is the difference between acceptance criteria and the definition of done?
Acceptance criteria is specific to one user story and describes unique feature behavior. The definition of done is a universal checklist (code review, testing, documentation) applied to every work item the team delivers.
What are the main formats for writing acceptance criteria?
Three formats are standard. Given-When-Then from behavior-driven development for complex scenarios. Rule-based checklists for simple constraints. Verification-based numbered steps for process-heavy workflows. Most teams mix formats depending on the feature.
When should acceptance criteria be written?
Before development starts. Teams define criteria during sprint planning or backlog refinement meetings. Writing criteria after coding begins causes rework, scope confusion, and misalignment between what the business wants and what developers build.
Can acceptance criteria change during a sprint?
Minor clarifications are acceptable. But significant changes mid-sprint signal poor planning. If criteria shifts dramatically, the user story should return to the backlog for re-estimation. Scope changes during active sprints hurt velocity and team morale.
What makes acceptance criteria testable?
Each criterion needs a measurable outcome with a binary pass/fail result. Vague language like “should be fast” fails. Specific language like “page loads within 2 seconds on a 4G connection” passes. Independence between criteria also matters.
How does acceptance criteria prevent scope creep?
If a requirement is not written into the acceptance criteria before the sprint starts, it does not belong in that sprint. This boundary protects the team from mid-sprint additions and keeps delivery timelines predictable across the project.
How many acceptance criteria should a user story have?
Between 3 and 10 is typical. Fewer than 3 usually means the story lacks detail. More than 10 suggests the story is too large and should be split into smaller, independently deliverable pieces during backlog grooming.
What is the connection between acceptance criteria and acceptance testing?
Each acceptance criterion becomes a test case. QA teams validate features against these criteria during user acceptance testing (UAT). Automated test scripts can also be generated directly from Given-When-Then formatted criteria using tools like Cucumber.
Conclusion
Understanding what is acceptance criteria in software projects comes down to one thing: getting everyone aligned on what “done” actually means before a single line of code gets written.
The format you pick matters less than the clarity you bring. Given-When-Then, rule-based checklists, verification steps. All of them work when the criteria stays testable and specific.
Teams that write acceptance criteria collaboratively during sprint planning catch edge cases earlier, reduce rework, and ship features that match stakeholder expectations. Teams that skip it pay for it later.
Whether you are running Scrum, Kanban, or a lean development workflow, make acceptance criteria a non-negotiable part of your development best practices. Your backlog refinement sessions, your validation process, and your release readiness reviews all depend on it.
Get the criteria right. The rest follows.
Many of his resources are available on various design marketplaces and for free on Codepen.
Over the years, he's worked with a range of clients and contributed to design publications like Design Your Way, Designmodo, WebDesignerDepot, WPDean, and Speckyboy, and Slider Revolution among others.
- 4 Scalable Hosting Providers for Growing Small Business Websites - April 9, 2026
- 7 Best Private Equity CRM Platforms for Middle-Market Deal Teams [2026 Comparison] - April 8, 2026
- Markdown Cheat Sheet - April 8, 2026
