How to determine if your requirements were met by your development team.

By Lenka Davis

Acceptance criteria is a list of statements that will tell you if the task is done based on your requirements. The criteria can be thought of as a test, a checklist of what the feature will and will not do. It sets boundaries and helps with communication.

In this article

• Communication

• Misunderstandings

• Tree swing metaphor

• An insurance policy

• How to write acceptance criteria

• Examples of acceptance criteria

Communication

“Communication is Key” is one of my favorite phrases. It's key to so many situations in business and in life. Keeping this in mind when working with teams of people allows you to focus on what people are trying to say. 

Think about the last time you were listening to a conversation between two people and you realized that both were using the same words, but meaning two completely different things. Having acceptance criteria written down aids the team in talking about the same thing while making sure the meaning is the same.

Acceptance criteria is a key communication tool that includes performance requirements and essential conditions, which must be met before project deliverables are accepted.

“The single biggest problem in communication is the illusion that it has taken place.” — George Bernard Shaw

Misunderstandings

We try to avoid as many misunderstandings in our lives as possible. One of the main reasons projects are derailed is due to misunderstandings. The misunderstanding of what is being built, how it needs to work, and what the user experience needs to be are just a few examples. 

How often have you asked for something to be built and when it is done you think to yourself “that is not what I asked for” or “they forgot to include this feature”.. If you have acceptance criteria written down it will be the list of testable tasks you go to when you ask this question. Acceptance criteria is a list of what you asked to be built specifically described in a way that can be tested, and results in a pass or a fail.

Tree swing metaphor

The tree swing metaphor is a common visual used to describe how different groups or individuals interpret the requirements of the development of a tree swing. You’ll find many versions of this on the internet, below is just one example. 

When you show this cartoon to a team it helps them understand how everyone hears and sees a request differently. Acceptance criteria needs to be written so in the end what is built is what the customer really needs.

Acceptance criteria can also be known as User Acceptance Testing or UAT, end-user testing, field testing or operational acceptance testing (OAT). In all cases these tests are done to discover or evaluate one of the items being tested.

An insurance policy

Think of acceptance criteria as an insurance policy on your requirements. Projects without clear acceptance criteria are at risk of taking longer than the initial timeline and costing more because missed or misunderstood requirements that have to be added to the project thus adding more cost. Or at worst, projects will be canceled.

Acceptance criteria:

• gives you the insurance you need to have insuring requirements were understood

• saves you time because there will be no additional items

• saves you money because you will not need to pay for missing items or misunderstood requirements to be built

How to write acceptance criteria

The two parts of acceptance criteria are a title and an explanation. The title is a short description of the situation or actions or output. The explanation will either be a list or several real life scenarios.

You can have criteria that is a list for requirements such as reports. The criteria would list the items that need to be on the report.

Or criteria can be scenarios describing each real-life situation that happens. The format of standard acceptance criteria is to list as many scenarios as you can and then explain what outcome you want that scenario to have. Use this format for scenario criteria:

Other things to keep in mind when writing acceptance criteria

• Write it before you start the development of the project

• think about what questions you want answers to in order to find out if the item is completed as you envisioned it

• Write it so it can be tested

  • For items that need to be on the screen or in a report list them out specifically and the testers will then be able to see them

  • Make the outcome to either pass or fail

• Write why you need the item and not necessarily how to solve it.

  • Creating a profile page for a paying customer is going to look a lot different from the admin page used by internal company administrators. One will be more visually appealing and user friendly to use then the other. Good development teams will know this if your criteria explains who a profile/admin page is used by and why you need the page.

• Write at least one criteria for each user story

• Any team member can write acceptance criteria however the product owner needs to approve it.

Examples of acceptance criteria

Let’s say we are writing a User Story for a travel App named Travel Today that suggests what cafes and museums to visit that day in the city you are in.

The user story is about how travelers can find what to do “TODAY” based on what other travelers did with a similar profile, the same likes and dislikes, in the same location in the past month. Here is a summarized version of the story:

USER STORY #1

As a traveler, I would like to log into the Travel Today app and see what cafes and museums I can visit today based on what city I am visiting.

For this story acceptance criteria describes the different scenarios that the App allows the user to do. There can be many scenarios.

Acceptance Criteria

Scenario 1 - Traveling alone for the day by walking, and using the metro

Given I am a traveler, and I am exploring the city alone, looking for a cafe and museum, then when I launch the Travel Today App in the morning, then I want to see suggestions in a news feed. It will allow me to select the city I am in, what I want to do (either cafe or museum or both) and how I am going to move around the city.

Scenario 2 - Traveling with family (aging parents) by walking, metro, taxi, boat and bus

Given I am a traveler, and I am exploring the city with family members and my family is aging parents, looking for a cafe and museum, then when I launch the Travel Today App in the morning, then I want to see suggestions in a news feed. I want to be able to select who I am with that day from a list of profiles that I already added, and how we are going to move around the city.

Scenario 3 - Traveling with a group of 4 couples, walking only

Given I am a traveler, and I am exploring the city with four other couples, looking for a cafe and museum, then when I launch the Travel Today App in the morning, then I want to see suggestions in a news feed. I want to be able to select who I am with that day from a list of profiles that I already added, and how we are going to move around the city.

Notice the following

Each scenario describes a slight difference between who the user is traveling with, and so the app developer would then be able to create different suggestions that apply to those conditions. Traveling alone is a lot different than traveling with a big group of friends. So, the size of a cafe or a museum might come into play here. And, how a traveler is moving around a city would determine how far away a certain cafe or museum would be recommended. All of these features would be associated with the cafes and museums added in the database that the app would search to make the best suggestions.

Other acceptance criteria would describe if the traveler would want to visit both cafes and museums or just one of them. It could also add features to add how many hours they have and what time of day they will be touring. These detailed features and many others would be decided on based on interviews with the initial users of the Travel Today app.

User Stories would also have to be written to describe how someone creates a profile and the types of information collected about each traveler. Another User Story would have to be written on what cities are to be in the initial release of the app and what database of cafes and museums would be used.

What is not in the acceptance criteria is:

1. How the UI (user interface) and UX (user experience) looks and works. If it is critical to the app then definitely add that in, however, it is better to have a whole separate user story with acceptance criteria on the UI and the UX. If this was an AR or AI based app then that would be a central part of the experience of using.

2. Anything super technical such as what database would store the cafe and museum information or the user information. This will be added to the technical user stories written by the technical team.

3. You can mention that you want users to change how secure or hidden their profiles are to be as a feature but let the technical teams handle the general security and privacy of the app.

Fun Fact

Explaining communication pitfalls when developing a product, the Tree Swing cartoon or sometimes referred to as the Tire Swing cartoon’s origin is unknown. There are many versions of the cartoon out on the internet that have added color and more pictures to fit the desired need. Versions have been found in books, offices and other publications from the late 1960, however, it is speculated that it could be from even earlier in the century. It is found in books about Quality Management (1989), in UK offices for Customs & Excise (1969), IT departments and even a San Francisco Examiner article for the Teaching Paper/This World publication (1975) where the cartoon is edited to fit the education sector, where ‘customers’ are replaced with ‘students’, ‘teachers’ in place of ‘marketing’ etc.

This article first appeared on www.flytosoar.com on April 11, 2022