Acceptance Criteria

One of the most important parts of any Agile product specification is the user story. This indicates the product’s capabilities from the perspective of its users. However, before a product team sets out to fulfill a user story, they must first know what qualifies as a success. That’s where the user acceptance criteria come in.

In this glossary definition, we look at acceptance criteria, provide some examples, and demonstrate how to create effective criteria that can guide your product development towards user success.

What are Acceptance Criteria?

Acceptance criteria are the set of conditions that a product must meet, in order for it to complete a certain user story. You should establish these criteria before any work on the feature starts.

The product owner or product manager typically writes the criteria, as they have the best understanding of the client or market requirements. However, the product team can also help write the acceptance criteria. This can determine if the team’s understanding of the product aligns with that of the product owner or manager.

Why are Acceptance Criteria Important?

Effective criteria can have a lot of positive impacts on the product development process.

• They narrow down the scope of the product. You can interprete user stories in isolation in a variety of ways, and therefore with various feature implementations. Acceptance criteria can illustrate what the limitations of each user story are, precisely describing how to fulfill them.
• They make it easier to test the product. Acceptance criteria have clearly defined conditions for success and failure. This means that you can easily test them during QA.
• They address invalid or negative outcomes. User stories only describe happy users who have fullfilled expectations of the product functionality. Acceptance criteria, on the other hand, can show alternative, non-successful user paths that must be accounted for.

What are the Types of Acceptance Criteria?

There are two main types of acceptance criteria, each with its own unique use cases.

1. Given/When/Then

Also known as scenario-oriented acceptance criteria, the Given/When/Then (GWT) format describes criteria in the form of a scenario that a user encounters. It has four components:

• Scenario: A description of the situation that the user will encounter.
• Given: The starting state of the scenario.
• When: The action that a user takes.
• Then: The result of the action in the previous “When”. 

There may be multiple Scenarios, Givens, Whens and Thens, which will be delineated by an “and” statement.

Here are Given/When/Then acceptance criteria examples for a hypothetical Netflix user story.

User Story: As a user, I want to be able to continue an episode from where I left off after closing the app or watching another show.

AC1:

AC 2:

2. Verification List 

You can’t write all criteria in the GWT format. In this case, you may opt to use a Verification List format, also known as rule-oriented acceptance criteria. This consists of a checklist of pass/fail statements that need completion to be successful.

The following Verification List examples illustrate what kind of statements you can put:

User Story: As a user, I want to register for an account at a website.

• The “Register” button on the homepage takes the user to a registration page.
• The user can input their desired username.
• User can input their desired password.
• The user has to retype their password in a verification box. 
• If the two passwords do not match, the user will see a warning message.
• For their password, the user has to use certain sets of characters (e.g. uppercase, lowercase, numbers, symbols) as defined by the security standards set by the product specification.
• If the user lacks these characters in their password,  a warning indicates what they’re missing.
• The user can’t type more than 22 characters in their password.
• The user can input their email address.
• After registering, the user receives a verification email.
• The user can input their verification details in a field.
• If the input is wrong,  the user sees a warning message.
• The user can resend their verification email.

This extensive verification list documents both positive and negative conditions for the user journey.

Tips for Writing Acceptance Criteria

Acceptance criteria look fairly straightforward to write. However, there are certain best practices for writing them that can make them more effective. Here are a few tips to get you started.

1. Don’t Include the Technical Details for Implementation

Just like user stories, acceptance criteria are not technical blueprints for your product team. Rather, they guide them towards building the features with their own methods. Therefore, you should write them in non-technical language. This will also help non-technical stakeholders understand them.

2. Choose Acceptance Criteria that Can be Tested

Acceptance criteria are verified during QA. Therefore, you should write them in such a way that they’re easily identified as pass or fail. Consequently, QA testers can quickly identify and mark any acceptance criteria that haven’t been achieved.

Some tips for this include:

• Writing in active voice with the user as the subject
• Using simple sentences
• Avoiding negative statements

3. Don’t be Too Broad, or Too Narrow

Acceptance criteria must not be very broad, as their objective is to limit the scope of a user story. They should also be focused enough to create testable criteria.

However, you should also avoid making them too narrow and specific. If you’re already touching on the exact way that a feature should be implemented, you might make it difficult for your developers to approach things.

Refining Your Approach to Product Development with Acceptance Criteria

Acceptance criteria can benefit your product development in many ways, but you have to write them well to be effective. It’s important to write them as early as possible, and with the right practices and approaches in mind. You should also know which methods of writing them are most appropriate for your user stories. Consequently, having this understanding of acceptance criteria will allow them to refine your approach and streamline development.