What are Acceptance Criteria in Software Development? Definition and Use Cases

In the process of creating a product, every person working on a given problem may have a slightly different approach to solving it. These don’t necessarily have to be big differences. It's enough to interpret the idea differently for the finished solution to not fully suit the product owner. Establishing clear and transparent acceptance criteria will help streamline your software development, as well as allow for the prevention of possible misunderstandings.

What are acceptance criteria? Definition

The acceptance criteria consist of a list of conditions used in the Agile methodology. They constitute a reference to user stories and complement the client's business goals. They define the conditions presenting the needs of users and the client, as well as the goals of individual functionalities. By correctly setting the acceptance criteria, the development team is able to fully understand how to approach the problem.

Who should create the acceptance criteria?

The person responsible for creating the criteria should have a broad knowledge of the project. This is particularly important because, in the software development process, the criteria will define what conditions should be met by individual functionalities. In many cases, the best choice will be the client who's in contact with the project from the very beginning. However, the product manager or product owner is also a frequent choice.

Acceptance criteria vs user stories

The acceptance criteria are based on individual user stories. These, on the other hand, are short descriptions of the problem. Their purpose is to signal and define what the problem is. Then why should you specify the acceptance criteria, and how do they differ from the user stories? The acceptance criteria define precisely the individual cases that the solution has to fulfill in order to be accepted. They complement the problem identification by specifying what functionalities a ready-made solution should provide. The criteria should also be constructed so as to leave no doubt regarding the correct performance of the product.

Why are the acceptance criteria important, and what are their characteristics?

Setting the acceptance criteria is a key point, as they reflect the needs of users. The criteria influence the software development process by defining what the development team should focus on. In order for the acceptance criteria to fulfill their purpose, they should meet several requirements.

• Clearly defining the goals of the solution. This allows for avoiding misunderstandings between the development team and the client.
• Short form. It's best if the criteria describe individual assumptions separately, without unnecessary and lengthy descriptions.
• Describing individual cases. In addition to identifying clear requirements that must be met, the acceptance criteria should return a yes or no result.
• Tests can be created on their basis. Thanks to clear requirements that the software must meet, it's also possible to create tests that verify these criteria.
• Making it possible to define the scope of work and estimated time. By precisely establishing the acceptance criteria for a given solution, it's possible to determine the complexity of the problem.

What if there are no acceptance criteria in the task?

In the absence of acceptance criteria, estimating the needed time can be quite a difficult task at the stage of starting the work. Due to the lack of clearly defined acceptance conditions, the team working on software implementation may create an artifact that differs from the client's expectations despite completing the user story. The lack of acceptance criteria defined before the work is being carried out causes compilations and code changes that may be avoided in a simple and quick way by specifying what conditions must be met by the completed solution.

Acceptance criteria types and formats

Acceptance criteria have one purpose but may be presented in several different ways. Therefore, the criteria can be divided into several categories:

1. Presenting the behavior scenario. They are characterized by the following phrases: when, if, as, after, and where. They define the software's circumstances and correct behavior in a given situation. They're the most commonly used criteria that allow for easy definition of tests and provide the test team with clear tasks.

If I am an authenticated user and have had an active account for over a year, I can check the account creation date in the account settings.

If an authenticated user loses their Internet connection, they'll see a "Connection failure" error.

2. Short checklist of goals. It reflects the set of rules that describe the behavior of the software. On the basis of these principles, specific scenarios can be created. This type of criteria is presented in the form of multiple points.

• The search button is in the header.
• The search button is blue with a white border.
• The search field allows you to enter numbers only.

3. Custom type of criteria. It helps in more individual scenarios where a more precise problem definition is required. It’s often a combination of two types.

Best practices in creating acceptance criteria

The approach to the problem and the definition of criteria may prove to be a difficult task, but a few good practices can help you meet the goals of the acceptance criteria issue.

1. Communication with the team. Talking to the development team can bring many good results, allowing you to look at the problem and approach it from a different angle. You shouldn't be afraid of the compromises that may result from such consultations.

2. Get to know the project and its goals well. Without a proper understanding of the problem and its circumstances, it's difficult to determine what may be the best approach to solving it.

3. Don't dig too deep into technical issues. The acceptance criteria should be defined in a common language. Not everyone may understand the technology and the correct approach.

4. Specify the fulfillment condition correctly. The criteria shouldn't be too general, nor should they be too precise, focusing on unnecessary details. They should be short and allow the development team to come up with an appropriate solution.

5. Start documenting the acceptance criteria at the beginning. Don't leave this for a later stage in the process. The acceptance criteria should be known and clear when the team starts working on the software.

Correctly defined acceptance criteria - examples

User story: As a logged-in user of a streaming service, I'd like to be able to check my payment status so that I know when to pay for the service.

Acceptance criteria:

1. If I am an authenticated user and I have an active subscription, I can see the information on the status of my payment in the account settings tab.

2. After logging in, I can see the payment date in the account settings.

3. After logging in, I can see the information on how to pay for the service in the account settings.

4. If the service is unavailable, I see the text "Please try again in a few minutes."

Let's take a look at another good example of the acceptance criteria.

User story: As a website administrator, I would like to be able to put graphics on the portfolio subpage.

Acceptance criteria:

1. The administration panel should allow for adding a file to the portfolio for mobile and desktop versions.

2. I can see the file for the mobile version on a phone when I go to the portfolio page.

3. I can see the file for the desktop version on a computer when I go to the portfolio page.

4. The graphics should always be visible before the rest of the website's content.

Imprecise acceptance criteria - examples

User story As a logged-in user of a streaming service, I would like to be able to check my payment status so that I know when to pay for the service.

Acceptance criteria:

1. The user can see the payment statuses.

2. I can see the payment information in the account settings.

3. When an error occurs, I can see the proper information.

In this case, the criteria don't define the details that the solution should meet. They're too general and may cause differences in understanding the problem by the development team.

Now let's see what the incorrect acceptance criteria will look like in the case of a notification from the website administrator.

User story: As a website administrator, I'd like to be able to put graphics on my website.

Acceptance criteria:

1. The administration panel should allow for adding a file.

2. I see graphics on the website.

3. In some cases, the graphics should be visible before the rest of the web page's content.

As was the case with the streaming service, the criteria were set too broadly. They don't present all the functionalities that the ready solution is to meet, and that the client expects.

Acceptance criteria – summary

Neglecting the acceptance criteria may cause many problems, and the very process of determining them allows for documenting the client's expectations. In addition, the criteria bring advantages to everyone by introducing clear and transparent communication within the team. Although different situations call for different solutions, the acceptance criteria apply everywhere because of their various types and formats. And testing new types of criteria that'll be useful to you is a good practice.

During our work, for example, when developing custom software, we regularly create the acceptance criteria. Therefore, we'll be happy to advise you on how to prepare such assumptions for your project. We can also analyze your other development processes.