How to write acceptance criteria: Definition, formats, examples - LogRocket Blog (2024)

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.

What are acceptance criteria?

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.

Why are acceptance criteria important?

Acceptance criteria play a vital role in product management because they:

• Provide clear guidelines — Acceptance criteria outline what is expected from a product or feature. This clarity helps to align all stakeholders, including developers, testers, and the business team, on what needs to be achieved
• Facilitate and understanding across teams — By clearly defining the expected outcome of a feature or product, everyone knows what to aim for and what will be considered a success, in turn minimizing the potential for misunderstandings
• Form a basis for testing — Testers can use acceptance criteria to determine whether a product or feature works as intended. If the developed feature meets all the outlined conditions, it can be marked as complete
• Help manage customer expectations and enhance satisfaction — When customers are involved in defining acceptance criteria, they have a better understanding of what to expect from the final product, leading to increased satisfaction when those expectations are met

Acceptance criteria in agile methodologies

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.

How to write acceptance criteria (7 steps)

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:

1. Identify the user story — Start by identifying the user story that your feature or product is designed to address. A user story describes an action or goal from the perspective of a user, such as, “As a blog reader, I want to be able to save articles so that I can read them later”
2. Define the desired outcome — Once you’ve identified your user story, it’s time to define what success looks like. This is where you describe the desired outcome in clear and specific terms. For example, “The blog reader can easily save any article and access it later from their personal reading list”
3. Detail the requirements — Next, detail all requirements that must be met for this outcome to be achieved. This could include technical specifications, design elements, or other factors that contribute to achieving the desired outcome
4. Create scenarios — Scenarios are specific instances of how users might interact with your product or feature. By creating these scenarios, you can better understand how your acceptance criteria will play out in real-world situations
5. Ensure clarity and simplicity — Acceptance criteria should be simple and easy to understand for everyone involved in the project, from developers and designers to stakeholders and end users
6. Seek feedback — Before finalizing your acceptance criteria, seek feedback from all relevant parties. This helps ensure that your acceptance criteria are comprehensive and aligned with everyone’s expectations
7. Review regularly — As work progresses on your product or feature, regularly review your acceptance criteria to ensure they’re still relevant and useful

Best practices for writing acceptance criteria

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:

• Start with the end in mind — Before you begin writing your acceptance criteria, it’s essential to have a clear understanding of what you want to achieve with your feature or product. What does success look like? What needs to happen for the product or feature to be considered complete?
• Be specific and concise — Avoid vague language and make sure each criterion is precise and easy to understand. Each criterion should describe a specific aspect of the functionality
• Use simple language — Your acceptance criteria should be easily understandable by all members of your team, regardless of their technical knowledge
• Focus on the user — Remember that acceptance criteria are about defining what will satisfy the user’s needs and solve their problems. Keep the user at the center of your writing process
• Collaborate with your team — Writing acceptance criteria should not be done in isolation. Involve your team in this process as they can provide valuable insights and help ensure that everyone is on the same page about what needs to be achieved
• Testable conditions — Make sure each criterion describes a condition that can be tested once development is completed
• Include both functional and non-functional requirements — While functional requirements describe what a product does, non-functional requirements deal with how well it performs certain functions or its qualities like security, performance, design, etc.

Acceptance criteria example

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:

• Users should be able to register using an email address
• Registration form must include fields for first name, last name, email address, password, and confirm password
• Password field should have validation rules – minimum eight characters long, at least one uppercase letter, one lowercase letter, one number, and one special character
• Users must verify their email addresses before they can log in
• Users should receive a confirmation email after successful registration
• If users try to register with an already registered email address, they should receive an error message
• Every step in creating these acceptance criteria focused on clarity and usability from both a developer’s perspective (who would use these as guidelines for building features) and from a user’s perspective (who would interact with these features)

Prescriptive vs. guiding acceptance criteria

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:

Let’s take a closer look at both approaches:

• Prescriptive acceptance criteria
• Guiding acceptance criteria

Prescriptive acceptance criteria

When someone refers to acceptance criteria, they usually mean prescriptive acceptance criteria.

You can think of prescriptive criteria as twofold:

• They serve as a detailed requirement list
• You can use them as user stories broken into smaller pieces

Example of prescriptive acceptance criteria

Let’s take a look at an example of prescriptive acceptance criteria.

Story: Transfer premium points

Acceptance criteria:

• A primary CTA button with text saying transfer points on the homepage.
• When a user clicks the button, they see a points transfer modal, which includes:
  • A friend dropdown list (mandatory)
  • An add a friend button.
  • A field for the number of points (mandatory)
  • A send button
  • A cancel button
• A user chooses a friend from a dropdown list
• Users can input between 100 and 1000 points to the field
• If they do not have enough points, show an error modal
• If they input too few or too many points, show an error modal
• When they click send, validate if all fields are correct
  • If not, throw a standard validation error
  • If yes, show another are you sure? modal
  • Clicking yes finalizes the transfer.
    • Clicking no moves the user back to the points transfer model
  • After finalizing the transfer, add the transaction to both the sender and receiver history, titled: Points transfer: {amount} from {userID} to {userID}

The purpose of prescriptive acceptance criteria

There are numerous reasons to use acceptance criteria in your product development work. The most common ones include:

• Managing expectations
• Managing scope
• Serving as a basis for estimates

Managing expectations

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.

Managing scope

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.

Serving a basis for estimates

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.

Serving as input to test plans

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.

Guiding acceptance criteria

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.

Example of guiding acceptance criteria

Story: Transfer premium points

Acceptance criteria:

• A user should be able to transfer up to 1000 points to a friend’s account
• The process should be easy and UX friendly
• Don’t overcomplicate. Let’s try to make an MVP within one sprint
• Include mechanics that prevent accidental points transfer
• Document and store all transfers

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.

Combining guiding and prescriptive acceptance criteria

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.

Acceptance criteria vs. definition of done

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

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:

• Given some initial context, …
• When an event occurs, …
• Then ensure some outcomes.

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 language and its use in writing acceptance criteria

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:

• A title that explains what’s being tested
• A Given step or steps that set up conditions
• A When step that describes the key action
• A Then step or steps that define the expected outcome

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.

Conclusion

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