What Is Acceptance Criteria In Agile

For a project to be successful, the team must fulfil the requirements of the clients to the letter, and the solution must be relevant to market and industry needs. Every feature should be acceptable to the client and should match their expectations.  

While all this sounds obvious, quite often in the real world, clients are very vague when explaining what they need. Lack of adequate and clear communication from the client might result in the team understanding the requirement in a wrong way because it was not properly articulated. They might then work on the feature over the duration of the entire sprint, only to find that it is rejected by the client when it is demoed at the end of the sprint. 

This is where well-defined Acceptance criteria play an important role. By documenting the requirements clearly, and listing out what the client would deem acceptable, the team knows exactly what is expected of them. There is no ambiguity, and the work progresses smoothly. 

So, what exactly are acceptance criteria in Agile? In this blog, we will walk you through why they are needed, the different types and structures of acceptance criteria, and some best practices in creating acceptance criteria.

What are Acceptance Criteria?

In order to mark a User Story as complete, there are a set of predefined requirements that must be met. These requirements are articulated in the form of acceptance criteria. They are also at times referred to as the “Definition of Done” as they must be met in order to consider that a user story can be moved to the “Done” column. 

Acceptance Criteria can be defined as the conditions that the product must meet, in order to be found acceptable by the user or the system. Each user story will have its own set of acceptance criteria, and just like the user story, they are also written from the perspective of the end user. 

Something to note here is that the acceptance criteria must be defined before the team starts to work on the story and should be finalised and frozen. If the criteria change while the work is in progress, there is a chance of failure of the task due to lack of clarity.

Why do you need User Story Acceptance Criteria?

The main purpose of acceptance criteria is to get complete clarity on the end users’ requirements.

When the acceptance criteria are clearly laid out, the team finds it easy to work on the user story and there is no ambiguity. Users are more likely to be satisfied with the results which will be in line with their expectations. 

Some of the reasons why we need to define the acceptance criteria include the following: 

• They get the team on the same page, aligning the client’s expectations to the goals of the development team. 
• They define and detail out the scope of the feature, giving precise details on the expected functionality. Any ambiguity is removed. 
• They define negative scenarios, such as what should happen if the user keys in the wrong password. They explain the consequences of such an action. 
• They help with establishing criteria for acceptance testing and QA, as each criterion that is listed out will be testable and will have pass or fail scenarios. 
• It becomes easier to conduct feature evaluations, as the acceptance criteria explain the exact requirements, including positive and negative scenarios, for each task. 
• They defend against scope creep in the middle of the sprint. 
• It becomes possible to plan schedules more realistically.

Roles responsible and how acceptance criteria are created

Acceptance criteria are usually written by the product owners at the time of creating the product backlog, or by the team when they are fleshing out the user stories during the sprint planning event. 

1. The process of creating the acceptance criteria begins with the user story prioritization.  
2. The product owner adds the user story to the sprint backlog and may also add the acceptance criteria. 
3. In case the client has adequate technical knowledge and product knowledge, they can also write the first draft of the acceptance criteria, in conjunction with the team. 
4. This is reviewed by the business analyst, project manager or requirements analyst who might add acceptance criteria if they are missing.  
5. The whole team discusses the user stories and the acceptance criteria and finalises them during the sprint planning meeting. 

Acceptance criterion types and structures 

There are three types of formats and structures for acceptance criteria that are generally followed: 

1. Scenario-oriented (Given/When/Then) 
2. Rule-oriented (the checklist template) 
3. Custom formats. 

Let’s discuss each in detail. 

Scenario-oriented acceptance criteria 

This format follows the Given/When/Then format, like so: 

• Given some precondition 
• When I do some action 
• Then I expect some result 

Let’s understand this with an example.  

Assume that you are using an online platform to study a course on Full Stack Development. You have a user id with a password and want to be able to recover the password in case it is forgotten. 

Here’s how the User story might read:  

As a user, I want to be able to recover the password to my account, so that I can access my account if I forgot the password.

Rule-oriented acceptance criteria format 

There could be some cases where it is not possible to use the Given/When/Then structure. Such cases can be addressed with the rule-oriented Acceptance Criteria format. 

Based on a set of rules that describe the behaviour of a system, certain specific scenarios can be drawn. These criteria are usually drawn up in the form of a bulleted list. 

Let’s understand this with the help of an example. 

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

In this case, the basic search interface acceptance criteria might look like this: 

• The search field is located on the top bar 
• Once the user clicks “Search, the search starts  
• A placeholder with a light blue-colored text states: “Where are you going?” 
• Once the user starts to type, the placeholder disappears  
• User types in a city, store name, street, or all combined and the search begins 
• The user can’t type more than 200 characters, including spaces

Other formats

While the two formats already described are the most common, if they do not suit your purpose, you can invent your own acceptance criteria. Each team can work with their own format, making sure that the criteria are written in simple and easy-to-understand English and cannot be misinterpreted. 

What are the characteristics of good Acceptance Criteria?

• First, your acceptance criteria must be testable. As they define and lay out the definition of done for the team, these tests should leave no room for misinterpretation, and should result in clear yes/no or pass/fail results. 
• The criteria should be written in a clear and concise manner. Avoid jargon, and use simple, direct language, avoiding negative words as much as possible. 
• Everyone on the team should understand the acceptance criteria. Leave no room for ambiguity. If there is anything that you, yourself, haven’t understood completely, get more details till you are sure about what you are writing. 
• Always write the acceptance criteria from the point of view of the user and in the context of a real user’s experience while using the product. 

Main challenges and best practices of writing acceptance criteria

While acceptance criteria appear to be easy enough to write, they often pose a challenge. Here are some best practices that you must keep in mind when writing acceptance criteria: 

1. Ensure that the criteria are well documented before the actual development begins, and that they are agreed upon by stakeholders and the team.  
2. When acceptance criteria are too specific, developers have no wiggle room for manoeuvring. 
3. Always convey the intent, not the solution. There could be multiple ways to achieve one result. 
4. Make sure that the criteria are achievable and define the minimum chunk of functionality. 
5. The criteria must be measurable. If they are too broadly defined, there is scope for misinterpretation by different individuals. 
6. Outline clearly the scope of work so that effort can be estimated properly. 
7. Technical details and jargon must be avoided. 
8. Use simple language and write in concise English that can be understood by everyone. 
9. The team and stakeholders must sign off on the acceptance criteria, after reviewing and understanding each line. 
10. Write testable AC, which allow testers to verify that all requirements were met, so that developers can easily understand whether the user story is completed or not. 

Pro Tips: 

Here are some tips on how the Acceptance Criteria can be worded, to have the most effect: 

• Write in simple, clear sentences. 
• Use the first person and the active voice. 
• Avoid long-winded sentences. Keep to the point. 
• Avoid using the word ‘not’, except where necessary to make the functionality clear. State the requirement as it should be, not as it should not be. 

Conclusion 

The practice of writing acceptance criteria may seem deceptively simple but are in reality a very important step in the development process. They serve to clearly document the requirements and set the expectations for the completed feature from the perspective of the end user. By using the practices that we have explained in this article, you can ensure that the acceptance criteria are defined the right way and leave no room for confusion.