Getty Images
Who writes acceptance criteria?
Product owners are usually responsible for acceptance criteria. But everyone who has a say in the final product should be involved in the process.
Acceptance criteria is a crucial part of the development process. But when it comes to who writes acceptance criteria, the answer isn't straightforward.
Acceptance criteria show how the user story meets the customers' needs, wants and objectives. The best acceptance criteria rely on input from Scrum team members within an Agile approach, customer success managers, user experience designers, helpdesk associates, and anyone who can provide a customer's perspective.
Quality should be baked into all aspects of development from the earliest stage, including the acceptance criteria.
On a development team, the product owner is most familiar with the needs and wants of customers. Therefore, they're responsible for translating that knowledge into the acceptance criteria. While the product owner writes the acceptance criteria, the process should involve the entire team to create a strong foundation for a quality product.
The Three Amigos
Acceptance criteria should be built out by the Three Amigos: the product owner, the developer and the tester. This approach is the foundation of acceptance test-driven development and calls for the quality engineering objective to build quality in from the beginning.
The Three Amigos approach improves acceptance criteria quality 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 the acceptance criteria based on INVEST guidelines. INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-appropriately and Testable.
The quality engineer's role in acceptance criteria
First and foremost, quality engineers are responsible for incorporating quality into requirements. They ensure that the entire team has a quality mindset and focus on it during all workshops, grooming sessions and discussions. Quality engineers also provide input into the testability of the acceptance criteria and review the tests for failures or ambiguities, which can cause further coding issues.
How to write acceptance criteria
There are two approaches to writing acceptance criteria. Acceptance criteria can be rules oriented or scenario oriented.
Rules-oriented acceptance criteria state the expected outcome of the product. This approach can be used for functional user stories. However, it is most successfully used for non-functional user stories -- for example, "The application must be scalable to 1,000 concurrent users."
Scenario-oriented acceptance criteria are used by Agile teams and describe a scenario that demonstrates how the customer uses the functionality. 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 outcome.
The scenario is a title or a summary of the behavior. Given provides the initial state or a short description of the user persona. When describes the action or the interaction between the software and the user. Then provides the expected outcome. Lastly, and expands upon any of the above.
An example of the Gherkin syntax:
Scenario: A pre-authorized user is recognized as eligible to register and allowed access to the registration screen.
Given that I am a pre-authorized user
And I am on the login screen
When I enter my email
And click the "register" call to action
Then my email is recognized
And I can navigate to the registration screen.
The Gherkin syntax is associated with the test automation tool Cucumber. However, they perform different tasks when it comes to acceptance criteria.
Cucumber test automation works specifically with the Gherkin syntax, translating it to code to create test scripts. The Gherkin syntax improves quality by clearly illustrating the acceptance criteria. In addition, when used with Cucumber, Gherkin facilitates behavior-driven development (BDD) and test automation because testers can load Gherkin-syntax statements into the tool.
Acceptance criteria drive quality engineering
BDD is a user-centric design and development approach based on how the user will interact with the application. When the Gherkin-formatted acceptance criteria work with Cucumber, the team creates automated tests based directly on the requirements. This setup leads to a technique called requirements as code. Requirements as part of the code embeds 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 entire team should be involved. In this way, acceptance criteria can form the basis for building quality into design and development.
