Editor’s note: This article was last updated on 5 July 2023 to include more context around the role of acceptance criteria in agile methodologies, concrete steps and best practices for writing acceptance criteria, and additional formats such as Given-When-Then and Gherkin language.
Almost every product manager and backlog owner uses acceptance criteria in one way or another. Acceptance criteria help us clarify requirements, give directions, and provide a checklist when reviewing the final work item.
However, all acceptance criteria are not created equal. There are various ways to use them.
In this guide, we’ll define what acceptance criteria are, how to write them effectively for your user stories, the role of acceptance criteria in agile methodologies, and more.
Acceptance criteria are a set of predefined conditions that a product or feature must meet to be accepted by the customer, project stakeholders, or the product management team. They serve as an essential guide for developers during the development process and help ensure that the final product aligns with the intended user needs and business goals.
Defining acceptance criteria in advance enables teams to better manage expectations, streamline communication, and reduce potential misinterpretations throughout the product development lifecycle.
Acceptance criteria play a vital role in product management because they:
Acceptance criteria play an indispensable role in guiding agile development teams toward their end goal: delivering value to users with high-quality software.
Agile practices emphasize collaboration, flexibility, and customer satisfaction. Acceptance criteria support these values by ensuring all team members understand what needs to be done and how success will be measured. They provide a shared understanding of requirements and prevent scope creep by keeping everyone focused on what truly matters: meeting users’ needs effectively and efficiently.
Furthermore, well-defined acceptance criteria enable effective testing processes within agile teams. By setting clear expectations upfront, testers can design more accurate test cases that align with the desired outcomes.
Acceptance criteria serve as a critical roadmap for product managers, guiding the development process and setting clear expectations for what a finished product or feature should look like.
Here’s a step-by-step guide on how to craft create clear, concise acceptance criteria that drive successful product development efforts:
Writing effective acceptance criteria is a crucial part of the product management lifecycle and you should take care to ensure it’s done with a clear end goal in mind. Below are some tips and best practices for writing clear, easy-to-understand acceptance criteria for your user stories:
Understanding and effectively utilizing acceptance criteria can be a game-changer. These crucial guidelines serve as a roadmap for development teams, outlining what a finished product or feature should look like from both technical and user perspectives.
Here’s an example to show what acceptance criteria can look like in practice. The criteria described below are designed to enhance communication within your team, streamline testing processes, better manage customer expectations and ultimately increase customer satisfaction with the final product or feature delivered.
Let’s say you’re managing the registration feature for an app. The acceptance criteria below describe the user’s experience when registering using their email:
There are two main approaches to crafting acceptance criteria: prescriptive and guiding. Understanding whether your project requires prescriptive or guiding acceptance criteria will ultimately depend on factors such as team dynamics, project complexity, and organizational culture.
The prescriptive approach tends to be more detailed and specific, outlining exactly how a feature should function or look. On the other hand, guiding acceptance criteria provide a broader view, giving developers more freedom to find solutions while still aligning with the overall goal.
The table below highlights the major differences between the two approaches:
|Prescriptive acceptance criteria
|Guiding acceptance criteria
|Specific details on how a feature should function or appearH
|High-level view of what needs to be achieved
|Limits developer creativity by defining exact requirements
|Promotes creative problem-solving within defined boundaries
|Reduces ambiguity and misinterpretation risks
|Requires strong communication to avoid misunderstanding
|May lead to longer development time due to strict guidelines
|Can speed up development time by improving flexibility
Let’s take a closer look at both approaches:
When someone refers to acceptance criteria, they usually mean prescriptive acceptance criteria.
You can think of prescriptive criteria as twofold:
Let’s take a look at an example of prescriptive acceptance criteria.
Story: Transfer premium points
There are numerous reasons to use acceptance criteria in your product development work. The most common ones include:
Acceptance criteria help manage expectations, between both the PM and the product team and the team and stakeholders.
They define precisely how a given feature will work. If your “I want to log in” user story has a “log in with Google” option in the acceptance criteria, that builds clear expectations that users will be able to log in with Google, but perhaps not necessarily with Facebook.
Good acceptance criteria leave no room for misinterpretation.
Who’s never had to cut scope to meet a deadline? Throw a rock.
Acceptance criteria help PMs with scoping activities, both when it comes to adding and removing the scope from the initiative. After all, you probably can’t remove the “I want to log in” user story, but you can strip it off fancy acceptance criteria and leave bare basics.
Acceptance criteria help you manage scope in a more granular, scalpel precision.
The vaguer the estimation object, the vaguer the estimate. Acceptance criteria provide the so-much-needed details to make development estimations more precise. After all, one could spend an hour or a week working on the “I want to log in” story, depending on the exact details of the login process.
Acceptance criteria serve as valuable input to the QA teams when it comes to preparing test cases. With properly-written acceptance criteria, they know exactly what to test and how a given functionality should work. Otherwise, they would probably need to ask the team, “is it a bug or a feature?” questions all the time.
At a certain level of the product team’s maturity, detailed descriptions of solutions are not only unnecessary, but often very limiting.
In such cases, writing acceptance criteria in the form of high-level, general objectives might be wiser.
It’s all about giving the team a high-level direction and letting them figure out the rest.
Story: Transfer premium points
Such a description gives enough details to provide boundaries for the initiative while giving the team the ownership to define the exact detail. At the end of the day, product teams are best-equipped to determine the actual solution, and product managers should do all we can to empower them to do so.
Different types of acceptance criteria have different uses for the product team.
Guiding acceptance criteria works well as a form of high-level boundary. Bring the problem to the team, let them discover potential solutions, and once you decide on a direction, set boundaries for the solution based on business needs and constraints.
Then, as the team defines the details of the solution (sometimes consulting with the product managers, sometimes autonomously), let them write more detailed, prescriptive acceptance criteria that will help them to manage expectations and scope.
Ultimately, it’s not guiding OR prescriptive acceptance criteria. Both of them serve different purposes at different stages of solution development.
One of the common confusions is the difference between acceptance criteria and the definition of done.
Although they serve a similar purpose, there’s one big difference. The definition of done is shared by all user stories, while acceptance criteria are story-specific.
The definition of done is shared by all user stories, while acceptance criteria are story-specific.
Also, acceptance criteria usually work as a development checklist, while the definition of done works as a holistic process checklist.
In other words, acceptance criteria includes things that should be built as a part of the feature, such as the “log in with Google” and “email me a magic link” features.
At the same time, the definition of done describes the whole journey of the user story (such as developing, testing, writing documentation, performing stress tests, and whatever is part of the definition of done).
Only when both acceptance criteria and definition of done are fulfilled, the story is fully complete.
Given-When-Then (GWT) is a semi-structured format for writing test cases. For product managers, it is a popular method for defining acceptance criteria.
This approach, also known as behavior-driven development (BDD), allows product managers to clearly express the expected behavior of a feature or product.
The Given-When-Then structure works like this:
For instance, consider a simple user story: “As a blog reader, I want to be able to save articles so that I can read them later.” The acceptance criteria using the Given-When-Then format might look like this:
Given that I am a registered user and logged in, when I click on the ‘save article’ button, then the article should be added to my saved articles list.
This format provides clarity and makes it easier for everyone involved in the project, from developers to stakeholders, to understand what needs to be achieved.
Gherkin is a domain-specific language used for defining acceptance tests in BDD. It uses plain English by default but supports multiple languages, making it accessible for non-programmers involved in software development projects.
The structure of Gherkin is similar to that of the Given-When-Then format. A typical Gherkin scenario consists of:
Here’s how our previous example might look written in Gherkin:
Scenario: Saving an article
Given that I am a registered user and I am logged in, when I click on the ‘save article’ button, then the article should be added to my saved articles list
Using Gherkin language when writing your acceptance criteria enables you to provide your team with easy-to-understand guidelines that help streamline both development and testing processes.
There are two types of acceptance criteria. Guiding acceptance criteria serve as a high-level direction and boundaries for the product team. Prescriptive acceptance criteria serve as a more detailed checklist that helps manage expectations and scope, estimate tickets, and plan test cases.
Less mature teams usually receive requirements with a predefined set of acceptance criteria. Once the team matures, though, they write their own acceptance criteria based on the problem they are solving and high-level guiding acceptance criteria.
Although acceptance criteria are similar in concept to the definition of done, while the former relates to a shape of a specific story, the latter defines the journey every user story should go through as a part of the development process.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Marc Singer discusses OrthoFi’s position to help dental providers find the right type of conversions, i.e., patients at the right risk level.
In this article, you’ll learn what a feedback loop is, the different types, and how to implement one effectively.
A requirements management software facilitates the process of handling project requirements from gathering ideas to project completion.
Leo Gong, VP of Product at Apartment List, talks about knowing when to plant a new seed in the business to expand growth opportunities.