Who writes the acceptance criteria?


Acceptance criteria are a crucial part of the development process. But when it comes to who writes the acceptance criteria, the answer is not straightforward.

Acceptance criteria show how the user story meets customer needs, wants, and goals. The best acceptance criteria are based on input from Scrum team members in an Agile approach, customer success managers, user experience designers, help desk associates, and any person who can provide a client’s point of view.

Quality should be built into all aspects of development from the start, including acceptance criteria.

In a development team, the product owner knows best the needs and wants of the customers. Therefore, they are responsible for translating this knowledge into acceptance criteria. While the product owner is writing the acceptance criteria, the process should involve the whole team to create a solid foundation for a quality product.

the three friends

Acceptance criteria should be developed by the three amigos: product owner, developer, and tester. This approach is the basis of acceptance test-driven development and calls for the goal of quality engineering to embed quality from the start.

The Three Amigos approach improves the quality of acceptance criteria through collaboration. The Product Owner represents and defines the needs of the users, who are the customers of the software. The developer provides the technical perspective. Meanwhile, the tester brings the testability perspective and reviews acceptance criteria based on the INVEST guidelines. INVEST stands for independent, negotiable, valuable, estimable, appropriately sized and testable.

The role of the quality engineer in acceptance criteria

First and foremost, quality engineers are responsible for integrating quality into requirements. They ensure that the whole team has a quality mindset and is focused on it during all workshops, grooming sessions and discussions. Quality engineers also provide feedback on the testability of acceptance criteria and review tests for failures or ambiguities, which can lead to further coding issues.

How to Write Acceptance Criteria

There are two approaches to writing acceptance criteria. Acceptance criteria can be rule-oriented or scenario-oriented.

INVEST Principles in Software Testing

Rule-based acceptance criteria indicate the expected outcome of the product. This approach can be used for functional user stories. However, it is used more successfully for non-functional user stories – for example, “The application should scale up to 1,000 concurrent users”.

Scenario-driven acceptance criteria are used by Agile teams and describe a scenario that shows how the customer uses the feature. The Gherkin syntax is the most common framework in the scenario-oriented approach.

The Gherkin Syntax

The Gherkin syntax is efficient and uses five statements to describe the user story and the user, how they will interact with the feature, and the expected result.

The script is a title or summary of the behavior. Given provides the initial state or a brief description of the user’s personality. When describes the action or interaction between the software and the user. So gives the expected result. Lately, and spans any of the above.

An example of the Gherkin syntax:

Script: A pre-authorized user is recognized as eligible to register and has access to the registration screen.

Given that I am a pre-authorized user

And I’m on the login screen

When I enter my email

And click on the call to action “register”

So my email is recognized

And I can access the registration screen.

The Gherkin syntax is associated with the Cucumber test automation tool. However, they perform different tasks when it comes to acceptance criteria.

Cucumber test automation works specifically with Gherkin syntax, translating it into code to create test scripts. Gherkin syntax improves quality by clearly illustrating acceptance criteria. Additionally, when used with Cucumber, Gherkin facilitates behavior-driven development (BDD) and test automation, as testers can load Gherkin syntax statements into the tool.

Acceptance criteria guide quality engineering

BDD is a user-centric design and development approach based on how the user will interact with the application. When Gherkin format acceptance criteria work with Cucumber, the team creates automated tests based directly on the requirements. This configuration leads to a technique called requirements as code. Requirements within the code embed quality expectations into the product.

You cannot overestimate the importance of well-defined and well-written acceptance criteria. Although the product owner is usually responsible for writing them, the whole team should be involved. In this way, acceptance criteria can form the basis for integrating quality into design and development.


Comments are closed.