Effective communication between clients and developers is the key to success in software development projects. If the clients’ requirements are fuzzy, developers can’t formulate their tasks accurately. Clear acceptance criteria, as other programming documentation, save time and lead to good results. 

What are acceptance criteria?

Generally, customer’s requirements are presented in the form of user stories and acceptance criteria. 

A user story implies describing in simple terms the most common situations of using particular tools.

Acceptance criteria are different for each user story; they determine how the software or its particular parts will behave for the final user. Every software product should be delivered in agreement with the clients’ requirements — and these predefined conditions are known as acceptance criteria.

Why are acceptance criteria so important?

Let’s take a look at what problems can be solved with the help of acceptance criteria. This will improve your understanding of their nature.

Define user stories

Acceptance criteria contain clear information about the needed features, which helps developers to understand which user stories are already covered and which ones are still left.

Describe worst-case scenarios

A worst-case scenario is a situation when the user behaves in an unplanned way or submits incorrect data. Acceptance criteria should also cover these cases and explain the desired response of the system.

Achieve effective communication

Acceptance criteria help the development team and clients to achieve a common vision of the project. This way, there are fewer chances that misunderstanding and mistakes can occur during realization.

Enhance acceptance testing  

Acceptance criteria are the core of user story testing. Every criterion has a positive and negative script, which can be checked with automatic testing.  

Prioritize tasks

Acceptance criteria let developers see the whole picture at once and identify the complexity of all tasks, which allows for better prioritization and better team performance. 

What are the kinds of acceptance criteria?

Acceptance criteria can be given to developers in different forms — scenario-oriented and rule-oriented. Also, the format can be defined by the user.

Scenario-oriented acceptance criteria

The scenario-oriented format has the Given-When-Then structure and can be named as GWT. This is how it works:

Given some conditions;

When I do a certain action;

Then I expect a specific result.

With GWT, there is no need to write a testing scenario, which saves testers’ time. Acceptance criteria, in this case, consist of several parts:

Scenario: the name of the described behavior or situation.

Given: the primary condition of the described scenario.

When: a certain user’s action that should trigger a particular response of the system.  

Then: the expected result of the user’s action or the correct response of the system.

And: any additions to any of the previous stages. 

To make the matter clearer, let’s review an example:

User story: A user wants to register with the website.

Scenario: Registration with the website. 

Given: The user is on the login page.

When: The user provides an email address.

Then: The system sends the link to the given email.

Given: The user receives the link.

When: The user clicks the link from the email.

Then: A page for generating a password opens.

There are many cases when scenario-oriented acceptance criteria are not effective, such as for describing design limitations when it is easy to skip important details. Also, it is not effective when user stories require different methods of quality control. In these cases, rule-oriented acceptance is used.

Rule-oriented acceptance criteria

There is a set of rules, which describe system behavior and enable developers to create scenarios. In that case, criteria are given as a list.

For example, take this user story: A user wants to exploit a search box to find a post on the blog.

Acceptance criteria can be the following:

  • The search box is placed in the right upper corner.
  • The search starts when the user pushes the Enter button.
  • The user can type in the keyword or the name of the post.
  • The user can type in English.
  • The user cannot exceed 100 symbols.
  • If the special symbol was written or another language was used, the system shows the text “Nothing found.”

User-defined format

Acceptance criteria can also be presented in any form, e.g., as a text or a schedule. The main rule is that the criteria should be written clearly and explicitly. 

Who should create acceptance criteria?

There are no strict requirements who should write acceptance criteria. This can be a project manager, a business analyst, a requirements analyst, or a product owner. If clients have technical competence, they can write the criteria themselves and discuss them with a team of developers. It is better to start with the prioritization of user stories and after that agree on controversial points.

How to write clear acceptance criteria?

Acceptance criteria don’t seem a too complex notion to understand, but writing them can be a problem. There are some tips, which can make this process easier

  • Document criteria before development

If acceptance criteria were documented before development, the team can foresee all users’ needs immediately. These criteria are also involved in the technical process planning. 

  • Leave room for variation

Particular acceptance criteria can lack some scenarios or be too specific. 

  • Avoid excessive detail

It is necessary to differentiate critical conditions from unnecessary details. If there are many details, the development team will be overburdened with small tasks and hence will need more time to deliver the project.

  • Refrain from synthesis

Wide acceptance criteria blur a user story, and hence developers can’t plan their time and prioritize tasks properly.

  • Use technical terminology

Acceptance criteria should be written with simple words, clear for non-technical specialists, managers, or stakeholders.

  • Reach agreement 

Stakeholders and developers should make sure that they understand acceptance criteria alike since the same problem can be solved in different ways. 

  • Document everything

Written and accurate acceptance criteria help developers to understand whether particular user stories have been covered. Testers will also be able to check all requirements. 

Writing acceptance criteria is an important part of the software development process.

It gives an understanding of the target behavior of the software, allows the development team to create a quality product, and helps the owner avoid bugs in the finished product.