Acceptance criteria are the conditions a product team must meet to mark a user story as complete. Product teams use acceptance criteria to make sure their products are high quality and address the needs of users.
What Are Acceptance Criteria?
Acceptance criteria are the predefined conditions that a product must meet to consider a user story finished. They follow a pass/fail format and focus on what goals need to be achieved, leaving room for product teams to decide how to achieve those goals.
While writing acceptance criteria may seem tedious, it’s an essential step for keeping product teams on track and enabling users to get the most out of a product. But acceptance criteria are only effective when properly executed. Below, we cover the process of writing acceptance criteria, examples and best practices for product development teams to consider.
What Are Acceptance Criteria?
Acceptance criteria are predefined conditions a product must meet for a user story to be completed. Only after these conditions are satisfied can a product team move on to the next user story. By nature, acceptance criteria follow a strict pass-or-fail system, meaning there’s no such thing as partially fulfilling acceptance criteria — either they’re met or they’re not.
For this reason, acceptance criteria focus on what goals need to be accomplished without specifying how they can be achieved. It’s up to product personnel and other team members to determine how they want to go about satisfying acceptance criteria.
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 is unique to each user story, meaning each user story has its own set of acceptance criteria.
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 clarifies what steps and features are needed to build an effective product and meet users’ needs.
- Transparency: Acceptance criteria explains what products must be able to accomplish, acting as requirements that keep all teams on the same page.
- Testability: Acceptance criteria provides 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?
There’s no hard and fast rule for when to write acceptance criteria, but product teams should finalize them before the development stage. As a first step, product managers can brainstorm acceptance criteria during backlog grooming sessions before presenting them during sprint sessions. Developers and other personnel can then offer feedback and help product managers refine the 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.”
As a result, it’s ideal to finish writing acceptance criteria just before the development process begins. That enables product leaders to work with the most up-to-date information on user stories, stakeholder preferences and other details. Teams should follow this method consistently, so each user story or product backlog item has its own set of acceptance criteria.
Who Should Write Acceptance Criteria?
While product managers (or product owners) are typically in charge of writing acceptance criteria, they often organize meetings for product personnel and members from different teams to review the criteria and make suggestions. Depending on how a company is structured, product teams may meet with members from engineering, software development, quality assurance, marketing, sales and customer success.
Product leaders often initiate conversations early on with users and other stakeholders too. Maintaining these open discussions allows product teams to get feedback from users and remain committed to a user-centered design.
An inclusive approach also allows product leaders to communicate the product strategy and keep all teams on the same page throughout the product development process.
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
The most straightforward format for acceptance criteria is a verification list of pass-or-fail statements. When writing the acceptance criteria, use the active voice, avoid passive statements and try to avoid long sentences with conjunctions. This keeps bullet points concise and makes it 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. In this case, acceptance criteria are written in a given, when, then formula that goes as follows:
- Given some precondition
- When a certain action is performed
- Then this should be the result
With a scenario-based approach, teams can consider a range of scenarios and how they want the product to operate under those scenarios. Product teams and technical personnel may then take wider possibilities into account and 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
There is no correct method for developing acceptance criteria. Whatever method your team chooses, here are a few examples to give you a better idea:
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
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
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
Using a ‘Tap-to-Pay’ Credit Card Feature
User story: As an in-person shopper, I want to be able to tap and pay with my credit card, so I can get through checkout faster.
Verification list acceptance criteria:
- Checkout pad contains ‘tap-to-pay’ icon in top-right corner above screen
- ‘Tap-to-pay’ icon beeps after shopper holds credit card barcode against it for one second
- ‘Payment processing’ message appears on the screen
- ‘Thank you for your payment’ appears on the screen after credit card data is processed
- Printer automatically prints paper receipt for shopper
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
Start brainstorming 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. Based on these discussions, make adjustments and repeat this feedback loop to further refine the criteria before diving into 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 be able to understand the acceptance criteria and what the goals of a product are without having to ask for 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 only be able to answer ‘yes’ or ‘no’ when deciding whether an acceptance criteria has been met. Simply describe what should be done, and avoid 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 all help you 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
You may be excited about a product, but that doesn’t matter if the product 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
Be open to making repeated adjustments during the planning stage. Finalize your acceptance criteria right before the product development phase. If you solidify criteria too early or wait until after development has begun, you may fail to address changes in user needs and waste resources building irrelevant products.
“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
Describing a product with technical jargon can make acceptance criteria less accessible. While engineers, developers and product managers may understand some 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 needs to strike a balance between brevity and detail. For example, ‘build a mobile app’ is a task that’s too broad and needs to be broken down further into steps. At the same time, including 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
It can be tempting to go beyond simply describing what needs to be accomplished and delving into how something could be done. However, this 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
Product owners or managers may be in charge of writing the acceptance criteria, but this isn’t an excuse to forego collaboration. 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.”
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.
