When working in Agile software development, you’ll often see references to acceptance criteria. While the phrase may sound unnecessarily confusing, it’s actually pretty simple. And while not every team uses it, it can be crucial to a successful launch. So what is acceptance criteria?

Acceptance Criteria Definition

The technical definition of acceptance criteria is, “the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.“Acceptance Criteria List with developers and testers looking at signs

Put more simply, acceptance criteria is a list of details (also known as requirements) about how a new software feature should work/look. This ensures that:

  • The feature is designed well. Otherwise, an important or helpful aspect might be left out – without anyone noticing until the very end.
  • It works the way it was intended. If the description is vague, developers might have to make assumptions about how each area should work. With acceptance criteria, developers know exactly what design and functionality is expected.
  • QA knows what to expect during testing. Even if a feature doesn’t feel broken, it might not work the way the product managers wanted it to. If there’s no acceptance criteria, testers can’t report these kinds of issues.

Although acceptance criteria applies to software, it might be easier to understand by imagining building a house. In that case, the acceptance criteria for the door might be something like:

  • User should be able to walk through the door
  • User should be able to enter the door through a wheelchair
  • The door should have four sides
  • The door should be seven feet high and four feet wide
  • The color of the door should be Sherwin Williams Direct Green paint shade
  • If the door is closed, user needs a key to enter

Good acceptance criteria should be easy to understand, but with enough detail to make sure it’s not too vague. It’s not always “one size fits all.”

Mobile phone showing a house with a doorBut it should always provide enough information for developers to build the feature, and for QA to test it. That doesn’t mean questions won’t come up during the software development process. But the general feature should be understandable.

Imagine if, instead of the above list, the following information were provided for building the entrance to a house:

It should have a door that locks.

That might be what comes to mind when first thinking of what a home entrance needs. But when comparing it to the previous list, you can see how even straightforward features need acceptance criteria.

Acceptance Criteria Format/Layout/Template

There are two main types of acceptance criteria, scenario-based and rule-based:

  • Scenario-based acceptance criteria uses a template to detail the exact user behavior/flow involved.
  • Rule-based acceptance criteria is more of a simple list of how the feature should look/work.

Scenario-Based Acceptance Criteria

Scenario-based acceptance criteria follows a “Given/When/Then” format. (The format is inspired by “behavior driven development,” although you don’t need to know about BDD to use this type of acceptance criteria).

“Given/When/Then” templates look like this:

Given [some aspect related to user behavior]

When [user takes a certain action]

Then [a certain result will happen]

If it needs to cover multiple different aspects, in the same scenario, it can also include “And” to continue the flow (between any of Given/When/Then statements). For example:

Given [some aspect related to user behavior]Scenario-Based Acceptance Critiera List on a website with team observing

And [some other condition is also happening]

When [user takes a certain action]

And [user does another action]

Then [a certain result will happen]

And [another result will happen]

(For scenario-based examples based on real features, check out the Examples section below.)

Rule-Based Acceptance Criteria

On the other hand, rule-based acceptance criteria doesn’t require fitting the information into a template. Instead, it’s a simple list of “rules” about how the feature should look/work.

For example, a rule-based list format might include:

  • All buttons should be a certain color
  • Login button should take user to a certain section
  • Sign Up button should be located in certain area
  • All buttons should be greyed out if certain requirements aren’t met

and many more. Although rule-based criteria has a simpler format, there’s no reason it can’t still be long and detailed. Read on for specific, real examples.

Acceptance Criteria Examples

Here are several examples using a basic login page, with scenario-based as well as rule-based formats.

Examples Using Given/When/Then (Scenario-Based):

Given user enters a valid registered email and password on the login page

When user clicks Login button

Then user should be taken to their account dashboard page

Examples Using Checklist (Rule-Based):

  • Email field requires valid registered email
  • Password field requires valid password
  • Login button should be teal
  • Login button takes user to account dashboard page

As you can see, the same basic aspects can be covered in both types.

Team Writing Acceptance Criteria for a Website

Who Writes Acceptance Criteria?

Usually multiple people or teams are involved in creating the acceptance criteria. However, it’s primarily written by the product manager (or “product owner”).

Developers are responsible for making the feature functional, and QA is responsible for confirming it’s usability. But acceptance criteria is created by the person or team responsible for deciding what new features to add to the product (no matter what type of app or website it is).

Writing Test Cases from Acceptance Criteria

When QA has acceptance criteria, it’s much easier to write test cases. There are several reasons for this:

1. There’s more clarity around how the feature is supposed to work. Without acceptance criteria, QA might have to guess how the feature should behave. For example, imagine a new feature allowing users of an app to send each other messages. QA might write test cases making sure that users could send messages in all types of scenarios. But what if the acceptance criteria would have included: “Users should not be able to send messages to anyone outside of their friends list”? Without those extra details, test cases might not accurately cover expectations about the feature.

2. Testers can use acceptance criteria as framework for test cases. Each line of the acceptance criteria can be expanded with test cases, to cover all possible user scenarios. For example, if part of the acceptance criteria is “Password field requires valid password,” you could expand that into the following test cases:

  • Password field should be case sensitive
  • Error message should appear if user clicks “Login” after entering invalid password
  • If user changes their password, the old password should no longer work
  • If user changes their password, the new password should work
  • etc.

However, although it’s not always easy, you can still write test cases without acceptance criteria if you need to. Learn more in our guide to writing test cases without requirements.

Acceptance Criteria in Agile ScrumAgile development Scrum logo

A big part of Agile involves making changes as the project develops. So can acceptance criteria change in the middle of a sprint? The answer is, “it depends.”

If the sprint has started but developers haven’t finished that feature yet, it might be fine to change the requirements. But it’s important to always check with developers first, and to keep others (like QA) in the loop.

Testers may have written test cases that no longer apply after the changes. In addition, the new amount of work might be too much for the developers to complete in time.

User Stories vs Acceptance Criteria

User stories and acceptance criteria go hand in hand. A user story describes the basic purpose of the new feature – an overview about how it will help users. Acceptance criteria lists the ways the feature should work from a more technical perspective. It’s common for tickets (for example in Jira or Trello) to list a user story at the top, followed by acceptance criteria.

Definition of Done

In order for the ticket (or feature) to be considered “done,” all of the criteria should be working. For example, let’s say that a user story was:

As a user, I want to be able to log in to access my account dashboard.

A user might be able to, as mentioned, log in to access their account dashboard. But the ticket wouldn’t be considered “done” if it also had acceptance criteria that included:

Login button should be teal

and the actual login button were, for example, yellow.

Sometimes a team will decide to launch a feature even with minor discrepancies. So they might mark a ticket as done (or create a separate ticket for addressing the remaining aspects) even without all criteria working. But in terms of the technical definition, it isn’t “done” unless all acceptance criteria passes.