Writing Acceptance Criteria Like a Pro

Let me start by answering the question: “What is the difference between User Stories and Acceptance Criteria?”

User Stories vs Acceptance Criteria – They Are NOT the Same!

To be clear, Acceptance Criteria (also known as Conditions of Satisfaction) are not User Stories. It is a common mistake to think of them as interchangeable. They are actually a part of a good User Story.

What Are User Stories and What Are Acceptance Criteria?

User Stories and Acceptance Criteria work together to help us create a bridge between business goals, which are made of words, and technological capabilities, which are made of code.

The User Story defines a business need by describing the WHO, WHAT, and WHY.

Acceptance Criteria, in contrast, are the conditions that must be met before a feature is considered ready for release. They describe the kind of behavior expected from the feature and provide developers with guidance as they implement it.

Each User Story typically has at least one Acceptance Criterion but could have many more depending on how complicated the Story is.

User Stories Are Like an artist’s sketch.
Acceptance Criteria Are the Paint!

Stories are deliberately vague to give the development team freedom to decide on the precise details of how to build something. Criteria are like detailed instructions for artists that tell them exactly what needs to be included in the painting.

To learn more about the parts of the User Story model, watch: What is a User Story? The Card, the Conversation, and the Criteria.

Are User Stories with Acceptance Criteria Only Used in Agile Development?

The User Story is a quintessential Agile artifact. But what happens when you’re not using Agile?

Organizations who deliver software in less agile and more “Waterfall ways” (Wagile, Scrumafall, etc) often express critical or complex Stakeholder Requirements in User Story format. This allows them to quickly scope a requirement and make Acceptance Test Cases easier to create.

In a lean/agile environment, Acceptance Criteria are created as the work is being done. Some of them are captured when the User Story is created, while others are written later during iteration planning meetings.

Perspective Is Everything!

Acceptance Criteria are conditions or rules that ensure that the product or application delivers the business value described in a User Story. They cover the nuances required to implement a feature. While the User Story is written from the user’s perspective, the Acceptance Criteria are written from the product’s perspective.

3 Simple User Acceptance Criteria Examples from a Real-Life Project

Let’s consider the User Story:

As a visitor to the website, I want to see all flights departing from my selected airport to my desired destination on the specified date to book the flight that meets my travel requirements.

To ensure that the product delivers what the Story describes, I capture the following Acceptance Criteria:

• The visitor is presented with a list of all available flights that match the search criteria
• If no flights match the search criteria, the visitor can choose the following:
  • alternative dates
  • alternative destinations
  • alternative departures
• Once the visitor selects a flight, the booking window is displayed

These are Acceptance Criteria that I came up when I first wrote the Story.

The Business Value of Writing Acceptance Criteria

Build Shared Understanding with User Story Criteria

The purpose behind Acceptance Criteria is:

• To ensure that the vision of the business communities and the technical teams are in alignment.
• To bolster mutual understanding among Author, Developers, and Stakeholders.
• To communicate the functional and non-functional requirements of a digital solution to the developers and testers.

Developers who know what rules the User Story must obey are less likely to deliver the wrong solution, while Stakeholders have control over what they consider a fully functional User Story.

Acceptance Criteria are your chance to fine-tune a Story, describing what you expect from a product in detail. They are the final proof of quality for any Story, helping both developers and QA testers understand exactly what they’re working on, resulting in fewer misunderstandings, speedier feedback, and smoother test runs. By clearly defining what is expected from the Story it helps minimize confusion, duplication of effort, or errors during development.

Effective Criteria Improve Estimates and Aid in Acceptance Testing

In addition, Acceptance Criteria moderate effort estimation. The more developers know about what they need to deliver, the better they can estimate the effort required to implement it. Without proper specifications, it’s difficult for developers to understand the scope of work and how long that work will take to complete.

Another advantage of Acceptance Criteria is that they can also be used to define negative test scenarios or failure conditions. These are situations in which the product reacts in a certain way (e.g., an invalid password pattern or an invalid combination of items in an order).

At some point in time, acceptance tests must be written to verify that each feature works properly. The Acceptance Criteria of the User Story should guide the construction of these tests. Therefore, it is a good strategy to create Acceptance Criteria that are specific enough to give clear instructions to QA testers.

Acceptance Criteria Formats You Should Know

If you have ever worked on a project, you have probably asked yourself, “How do I write Acceptance Criteria; what format should I use?”

There are as many ways to write Acceptance Criteria as there are people writing them. The most important part in writing Criteria is to specify the requirements from the product’s perspective. This can be tricky, but it is critical because understanding what the application should do instead of how it will be built, reduces ambiguity and helps you ensure the system will behave in an expected manner.

What Are the Different Types of Acceptance Criteria?

The formats used range from simple Acceptance Criteria checklists to complex Business Rules and conditions. A checklist is a list of statements that describe what needs to be accomplished. Another common format is the Business Rules and conditions, which are a set of specific rules that define how your software should behave. Some teams even use Given-When-Then Scenarios although that is mostly used in  Acceptance Testing.

User Acceptance Criteria Examples: Checklists

Writing Acceptance Criteria checklists is an easy and effective way to communicate with your team. It also increases team productivity and eases collaboration.

Here is an example of a User Story with Acceptance Criteria in the form of a checklist that communicates to the developers what the Story intends:

As a new user, I can join a group, to participate in a discussion.

Acceptance Criteria:

• User can create a profile
• User can browse groups
• User can select a group
• User can request to join a group
• User can read chats of other members
• User can comment on chats

Writing Acceptance Criteria in the Form of Business Rules

Business rules are a form of business requirements that, once created, do not require programmer involvement to be changed. They make excellent Acceptance Criteria.

For example, if a marketing department wants to give a 10% discount to students living in Florida during the winter season, it needs to specify this option in Business Rules. Marketing wants to be able to make these changes on the fly to adapt to current market changes and stay competitive. Business Rules give them that ability.

In their simplest definition, Business Rules are policies that define, trigger, or restrict business activities. They are an integral part of User Stories, and describe the processes, definitions, and constraints that apply to the business.

Business Rules are not just about technology – they relate to people, processes, business behaviors, and systems. They help the organization achieve its goals.

To clarify the terms:

• Business Rules give you the criteria and conditions for making a decision.
• A User Story or Business Requirement enables the implementation of and compliance with a Business Rule.

If you define the Acceptance Criteria for a User Story in the form of Business Rules, you can quickly clarify a complex Stakeholder Requirement. Here is a sample of this Acceptance Criteria type:

To reduce the abandonment rate, underwriters can accept or reject applications for automobile insurance within 3 business days.

When does the business day begin and when does it end? Are weekends business days? Until you know the answer to these questions, you can’t measure whether the software implements the User Story correctly.

The most common form of a Business Rule is a statement of fact. To ensure a correct implementation of this User Story, you could write the Acceptance Criteria to reference (or even quote) the specific Business Rule:

BR107: The business day starts at 8 am and ends at 5 pm UTC-7 Mondays through Fridays except on legal US holidays.

Writing Gherkin Acceptance Criteria Using the Given-When-Then Format

The Gherkin format is becoming the preferred method for writing Acceptance Criteria since they can easily be expanded into Acceptance Tests. The Gherkin syntax is easy to understand and easy to read; you describe the context (Given), what needs to happen (When), and what the outcome should be (Then).

For example:

SCENARIO: Customer with long job history and excellent credit applies for a loan
GIVEN applicant has been on the job more than 5 years
AND credit is excellent
WHEN customer submits loan request
THEN approve loan
AND request cosigner

The Given-When-Then structure is particularly effective because it provides enough context for developers to understand what they need to build, while being concise enough so that it does not get in their way during development.

Writing Acceptance Criteria in Gherkin syntax focuses on the execution of business logic rather than on the technical details. The benefit of this approach is that tests can be written by business analysts, domain experts, and testers, rather than developers.

Gherkin is easy to understand and easy to read. Given, When, and Then are the three main keywords that make up the Gherkin syntax:

• Given (context): The context in which the feature is used. This may include: preconditions, environment details, and any other relevant information necessary to ensure the scenario delivers the expected outcome.
• When (event): The event that triggers the feature being used. This may include: actions taken by users or automated actions taken by the system itself.
• Then (result): The expected outcome of executing that action. This could be confirmation that something happened correctly (e.g., success message), but it may also mean failure (e.g., error message).

Since the Given-When-Then format is so popular for writing Acceptance Criteria and Tests, I wrote a blog post just on the Gherkin Given-When-Then approach titled “A Formula for Great Gherkin Scenarios (with Given-When-Then Examples)“.

Using Functional Decomposition to Write Acceptance Criteria

If a User Story is complex or multi-faceted, Acceptance Criteria can reveal individual functions that must work together to deliver the business value of the User Story.

A useful technique for defining Acceptance Criteria is to break the User Story down into functions that users will interact with.

A function could be something as simple as pressing a button or typing in a username and password. It could also be something more complex, like filling out an entire form.

This method helps developers clearly understand the functionality and characteristics needed for a User Story to be implemented according to user expectations.

A quick way to get to a function list is with a technique called Functional Drill-down or Feature Decomposition”. This method is often used to split or break down large User Stories, and as a bonus, you get non-functional requirements that the Story must fulfill. It consists of looking at a User Story to identify:

• Functional Features the solution must perform and their related data.
• Quality Requirements (a.k.a. Non-functional Requirements) that define the properties and characteristics the digital solution must have.
• Constraints, or absolute limitations, rules, laws, regulations, and environmental factors which must be considered in the solution.

Every minute spent on poorly written User Stories and requirements is a minute wasted! Avoid common mistakes and learn to create the best functional Agile Story Criteria for your software team.

Large User Story: Example with Acceptance Criteria

Let us examine the following User Story:

As online shopper, I want to order a new book to read it at home.

Your functions could be:

• Add the book to the shopping cart
• Check out the different payment options
• Ship the product to the customer based on the shipment choice

The functions are not very detailed, but this is fine for a first set of User Story Criteria. In an agile environment, User Stories will be fleshed out closer to development. Acceptance Criteria for those lower-level Stories will be defined later in the software development lifecycle.

Small User Story: Sample Acceptance Criteria

Here is another example, but with a smaller User Story:

As an Agent, I can allow a premium discount for safe drivers to sell more insurance policies.

This Story blatantly states one function:

• Calculate Premium Discount.

Next, look for implied functions. A discount is always a percentage of the base amount. That implies that the application must know the premium to be able to calculate a premium discount.

That adds the functions:

• Calculate Premium Discount
• Calculate Premium

Furthermore, the Story refers to “safe drivers” as a group of people who qualify for this premium discount. How can the application recognize a “safe driver”? In discussing this with the SME, you discover that a safe driver is one who has not had an accident or traffic violation in 3 years.

Based on this information, you realize that you need a function to evaluate the applicant’s driving record to decide whether they fit this profile, ergo the function, “Evaluate Driving Record”.

This type of Acceptance Criteria using functional break-down is more suited to later stages of development, such as during Release and Sprint Planning.

Following is an example for high-level functional Criteria:

Closing Thoughts

I hope this blog post has given you some useful tips and tricks on how to write good Acceptance Criteria for your User Stories.

Writing Acceptance Criteria can be a little intimidating at first, but it will become easier as you keep doing it. It’s important that you don’t let these tips limit your creativity — instead, view them as a set of guiding principles that will help you create better User Stories.

Having the ability to clearly lay out Acceptance Criteria is a helpful habit to get into. More than that, having these Criteria written down can help you stay focused when you’re dealing with difficult users and trying to solve a tricky problem.

But to get the most out of User Story Criteria, it is necessary to know how to do it effectively and how to avoid common pitfalls.

• Any surprises that you encountered with this approach?
• How has it helped with your User Story development?
• Do you have something new to share with us about your experiences working with User Stories?

Please share your thoughts and insights below!!