In the development process, acceptance criteria are the pre-established conditions that determine whether a product or feature meets all the requirements of the end user or customer. They are a set of pass/fail statements, and only once they are met can a product team mark a user story as complete.
What Are Acceptance Criteria?
Acceptance criteria are the predefined conditions that a product or feature must satisfy to be considered complete by its intended users. They follow a pass/fail format and solely focus on what goals need to be achieved, leaving room for product teams to decide how to achieve those goals.
What Are Acceptance Criteria?
Acceptance criteria refers to a set of conditions that a product or feature must meet to satisfy the requirements of its end users or customers.
Because there’s no such thing as a user partially completing an action, products and features either pass or fail acceptance criteria, with no in-between. While acceptance criteria state the desired action, they don’t explain how it should be done. This gives product teams leeway to decide how a product can best address user needs later on.
High-quality acceptance criteria are often defined by these characteristics:
- Clear: Plain language is used instead of complicated terms and team-specific jargon, so anyone can understand the criteria.
- Concise: Only essential details are included, so acceptance criteria refrain from covering details like how a product or feature should address user needs.
- Testable: Teams are able to answer ‘yes’ or ‘no’ when deciding whether acceptance criteria have been satisfied during testing.
- User-centric: Emphasis remains on the user’s perspective, so teams craft acceptance criteria with the goal of meeting users’ needs.
Why Are Acceptance Criteria Important?
Whether a product team follows the scrum or agile methodology, acceptance criteria can improve the product development process in a few ways:
- Clarity: Acceptance criteria clarify what steps and features are needed to build an effective product and meet users’ needs.
- Transparency: Acceptance criteria explain what products must be able to accomplish, acting as requirements that keep all teams on the same page.
- Testability: Acceptance criteria provide a clear method for testing and determining whether a user story is finished, removing any room for uncertainty.
- Efficiency: By establishing concrete requirements for all teams to adhere to, acceptance criteria can help teams avoid confusion and get tasks done faster.
- Product success: Teams with well-defined acceptance criteria can meet product deadlines, avoid costly mistakes and design products that address users’ needs — all of which contribute to a product’s success.
When Should You Write Acceptance Criteria?
Acceptance criteria are brainstormed during backlog grooming sessions and presented during sprint sessions, where they get feedback from developers and other personnel. They are finalized just before the development process begins, so product leaders have the most up-to-date information. This method consistently ensures each user story or product backlog item has its own set of acceptance criteria.
“I really like to give a high-level overview and a few bullet points at the start of the project,” said Zalak Trivedi, product manager at Sigma Computing. “As we are ironing out the design and as developers actually start putting code in, then at that point I flesh it out a lot more.”
Who Should Write Acceptance Criteria?
Product managers, other product personnel and members from teams like engineering, software development, quality assurance, marketing, sales and customer success all contribute to writing acceptance criteria. Conversations with users and other stakeholders take place early on as well to get user feedback. This approach keeps all teams on the same page about the product strategy.
How to Write Acceptance Criteria
There are two main methods product development teams rely on for writing clear acceptance criteria.
1. Create a Verification List
A verification list is a straightforward, rule-based way to write acceptance criteria. It’s a set of pass-or-fail statements. When writing the acceptance criteria, use the active voice, avoid passive statements and avoid long sentences with conjunctions. Keep each bullet point concise, so it’s easier to craft statements that can only be answered ‘yes’ or ‘no.’
2. Follow a Scenario-Based Template
The scenario-based format — also known as the Gherkin format — uses the Gherkin language to frame acceptance criteria. Write acceptance criteria in the following given, when, then formula:
- Given some precondition
- When a certain action is performed
- Then this should be the result
This approach encourages teams to consider how they want the product to operate under various scenarios, so product teams and technical personnel conduct more thoughtful testing.
“[The Gherkin format] gets your engineering lead’s brain turning, the developer’s, and then the QA person is really thankful because they’re able to have a really clear path,” said Ashley Grace Jefferson, founder of Ashley Grace Consultancy and a fractional product manager. “But then they’re also able to think of edge-case scenarios and try things out that maybe you or your devs didn’t get to try.”
Acceptance Criteria Examples
Here are a few examples to give you a better idea of how to write acceptance criteria:
1. Accessing an Online Shopping Cart
User story: As an online shopper, I want to access my shopping cart, so I can review my order.
Scenario-based acceptance criteria:
- Given that I have placed items in my shopping cart
- When I click on the shopping cart symbol in the top-right corner of the webpage
- Then I can view the items I’ve saved so far in my shopping cart
2. Paying an Electric Bill Online
User story: As a renter, I want to be able to view my electric bill online, so I can pay it.
Verification list acceptance criteria:
- Dropdown menu appears when renter clicks on menu icon in top-right corner of webpage
- Dropdown menu contains ‘pay my bill’ section
- User is prompted to enter login credentials when clicking ‘pay my bill’
- User gets sent to billing page
- User can view current amount due and ‘make payment’ button below current amount
- User gets sent to payment page when clicking ‘make payment’
- User can enter payment information and hit ‘pay’ button at bottom of page
3. Checking the Status of a Rideshare
User story: As a mobile app user, I want to check when my rideshare will arrive, so I know how long my wait time is.
Scenario-based acceptance criteria:
- Given that I have ordered a ride through the rideshare app
- When a driver accepts my request
- Then I receive an alert telling me their ETA
Acceptance Criteria Best Practices
Emphasize the User’s Perspective
Initiate and maintain open conversations with customers and stakeholders to get a sense of what their pain points are and what they need help achieving.
“Have a champion customer,” Trivedi said. “Because now you’re building towards a use case and a problem that you want to solve.”
Write Acceptance Criteria Early and Often
Brainstorm acceptance criteria at the very beginning of the product development process. Once you have a rough outline, show the criteria to stakeholders and collaborate with team members during product backlog and sprint sessions. Make adjustments and repeat this feedback loop to further refine the criteria before the product development stage.
Explain Acceptance Criteria in Simple Terms
Stick to plain language when writing out acceptance criteria, avoiding specialized vocabulary and technical jargon. Personnel in non-technical departments like marketing, sales and customer success should understand the acceptance criteria and what the goals of a product are without needing clarification.
“I more so talk about the acceptance criteria in just human terms,” Jefferson said. “Because at the epic level, I would want someone picking it up to understand ‘here’s what we’re doing’ in pure English.”
Keep Acceptance Criteria Concise
Develop concise acceptance criteria. Use an active, first-person voice and avoid conjunctions. This will help you better define and stay focused on the scope of the project, which makes it easier to set concrete goals and ensure the overall vision for a product is realistic.
Make Sure Acceptance Criteria Are Testable
Teams should be able to answer ‘yes’ or ‘no’ when deciding whether acceptance criteria have been met. Describe what should be done without discussing how it should be done. This way, developers and engineers can test the criteria and know whether a test has passed or failed.
Establish a Collective Approach
Seek insights from team members, especially those working on the backend. Engineers, developers and QA analysts can help determine whether the acceptance criteria are achievable and clear, leading to a more efficient product development process.
“Talk to your fellow product managers,” Jefferson said, “but also make friends with the engineering leads.”
Acceptance Criteria Mistakes to Avoid
Forgetting to Center the User
A product is useless if it fails to address the unique needs of users. Not asking potential customers for their input on acceptance criteria can result in you losing focus of the scope and building products that don’t actually help customers.
“Anytime you finish a user story or you believe you have a minimum viable product (MVP), put that in front of a customer,” said Krishna Vemulapali, co-founder and chief product officer at Trellis. “Get their feedback and repeat that cycle over and over again.”
Finalizing Acceptance Criteria Too Early or Too Late
If you solidify criteria too early or wait until after development has begun, you’ll waste resources building irrelevant products that don’t address changes in user needs. Adjust acceptance criteria during the planning stage and finalize them right before the product development phase.
“Acceptance criteria should be the first thing itself,” Vemulapali said. “And you will refine it as you build your MVP, as you finish your story.”
Using Technical Language
Technical jargon makes acceptance criteria less accessible. While engineers, developers and product managers may understand specialized vocabulary, members from marketing, sales and customer success may be left in the dark. This can lead to confusion over the product strategy.
Creating Acceptance Criteria Too Broad or Narrow in Scope
Acceptance criteria need to be brief yet detailed. For example, ‘build a mobile app’ is too broad and needs to be broken down further. At the same time, paragraphs of directions may make the acceptance criteria too narrow in scope and too tedious for technical teams to execute.
Losing Sight of the End Goals
Delving into how something could be done is overstepping the boundaries of acceptance criteria. If teams forget to keep the goals of a product in mind, they may write acceptance criteria that are too tedious and muddled with details.
Failing to Involve Team Members
Software developers, engineers and other technical personnel can ensure the criteria remain practical while marketers and customer success reps can share input to keep the criteria accessible to non-technical personnel. Missing out on these perspectives only leads to more headaches later on.
“If it’s just the product owner or product manager building this in a vacuum without the input from other team members, it’s a recipe for disaster,” Trivedi said. “You find things out too late when you already put in so much investment into the process of building something.”
Acceptance Criteria vs. User Story
A user story describes the end goal of a product’s user. It is only a few sentences of plain language and written from the perspective of the user.
While user stories explain why a product or feature needs to be built, acceptance criteria depict what needs to be done to design this product or feature. These criteria act as a technical checklist to help product teams test if they’ve built products that will help users accomplish their end goals.
Acceptance Criteria vs. Definition of Done
Definition of done is a set of criteria that all user stories must meet to be considered complete. For example, all user stories may have to undergo peer review sessions or be free of bugs. Acceptance criteria are unique to each user story, meaning each user story has its own set of acceptance criteria.
Frequently Asked Questions
What is an acceptable user criteria?
Consider a scenario where an online shopper wants to check out an item. An example of acceptance criteria in this situation could be, “User must enter payment information before pressing the ‘pay’ button at the bottom-right corner of the page.”
What determines acceptance criteria?
Acceptance criteria are determined by the end goals of the user and the type of product teams want to build. Acceptance criteria establish the requirements that must be met for a product to be considered finished and ready to address users’ specific needs.
