Acceptance criteria main purposes

Clarifying the stakeholder’s requirements is a high-level goal. To make the purposes of AC clearer, let’s break them down.

Feature scope detalization. AC define the boundaries of user stories. They provide precise details on functionality that help the team understand whether the story is completed and works as expected.

Describing negative scenarios. Yor AC may require the system to recognize unsafe password inputs and prevent a user from proceeding further. Invalid password format is an example of a so-called negative scenario when a user does invalid inputs or behaves unexpectedly. AC define these scenarios and explain how the system must react on them.

Setting communication. Acceptance criteria synchronize the visions of the client and the development team. They ensure that everyone has a common understanding of the requirements: Developers know exactly what kind of behavior the feature must demonstrate, while stakeholders and the client understand what’s expected from the feature.

Streamlining acceptance testing. AC are the basis of the user story acceptance testing. Each acceptance criterion must be independently testable and thus have a clear pass or fail scenarios. They can also be used to verify the story via automated tests.

Feature estimation. Acceptance criteria specify what exactly must be developed by the team. Once the team has precise requirements, they can split user stories into tasks that can be correctly estimated.

Acceptance criteria types and structures

AC can be written in different formats. There are two most common ones, and the third option is to devise your own format:

scenario-oriented (Given/When/Then)

rule-oriented (checklist)

custom formats

As the first and the second formats have very specific structures, we’ll mostly focus on them. However, you may find that other formats fit your product better so we’ll briefly touch on them as well.

Scenario-oriented acceptance criteria

Scenario-oriented format of writing AC is known as the Given/When/Then (GWT) type.

Given some precondition

When I do some action

Then I expect some result

This approach was inherited from behavior-driven development (BDD) and provides a consistent structure that helps testers define when to begin and end testing a particular feature. It also reduces the time spent on writing test cases as the behavior of the system is described upfront.

Each acceptance criteria written in this format has the following statements:

Scenario — the name for the behavior that will be described Given — the beginning state of the scenario When — specific action that the user makes Then — the outcome of the action in “When” And — used to continue any of three previous statements

When combined these statements cover all actions that a user takes to complete a task and experience the outcome.

Let’s look at some examples.

Example 1

User story: As a user, I want to be able to recover the password to my account, so that I will be able to access my account in case I forgot the password.

Scenario: Forgot password

Given: The user has navigated to the login page

When: The user selected forgot password option

And: Entered a valid email to receive a link for password recovery

Then: The system sent the link to the entered email

Given: The user received the link via the email

When: The user navigated through the link received in the email

Then: The system enables the user to set a new password

Example 2

User story: As a user, I want to be able to request the cash from my account in ATM so that I will be able to receive the money from my account quickly and in different places.

Acceptance criteria 1:

Given: that the account is creditworthy

And: the card is valid

And: the dispenser contains cash

When: the customer requests the cash

Then: ensure the account is debited

And: ensure cash is dispensed

And: ensure the card is returned

Acceptance criteria 2:

Given: that the account is overdrawn

And: the card is valid

When: the customer requests the cash

Then: ensure the rejection message is displayed

And: ensure cash isn’t dispensed

Rule-oriented acceptance criteria format

In some cases, it’s difficult to fit acceptance criteria into the Given/When/Then structure. For instance, GWT would hardly be useful for the following cases:

You’re working with user stories that describe the system level functionality that needs other methods of quality assurance.

The target audience for acceptance criteria doesn’t need precise details of the test scenarios.

GWT scenarios don’t fit to describing design and user experience constraints of a feature. Developers may miss a number of critical details.

You can address these cases with the rule-oriented AC format.

The rule-oriented form entails that there is a set of rules that describe the behavior of a system. Based on these rules, you can draw specific scenarios.

Usually, criteria composed using this form look like a simple bullet list. Let’s have a look at an example.

Example

User story: As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options.

Basic search interface acceptance criteria

The search field is placed on the top bar

Search starts once the user clicks “Search”

The field contains a placeholder with a grey-colored text: “Where are you going?”

The placeholder disappears once the user starts typing

Search is performed if a user types in a city, hotel name, street, or all combined

Search is in English, French, German, and Ukrainian

The user can’t type more than 200 symbols

The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”

Other formats

Most user stories can be covered with two formats mentioned above. However, you can invent your own acceptance criteria given they serve their purposes, are written clearly in plain English, and can’t be misinterpreted. Some teams even use plain text.

Sometimes, your criteria may be specified as an example of system behavior: