Why Acceptance Criteria Matter for Your Software: Benefits, Examples, and Best Practices

Misunderstandings within software development teams can cause costly rework, shift delivery deadlines, or even undermine the quality of the final product. A common reason for such misunderstandings is poorly prepared acceptance criteria.

Agile documentation clearly defines how each product feature must work, providing a uniform understanding of work to be done among all team members. In this article, we examine the definition of acceptance criteria, benefits they can bring to a project, and practices that Apriorit business analysts use to make quality and useful criteria.

This article will be useful for project owners and company leaders who want to ensure an efficient project development workflow and make sure all team members are on the same page.

What are user stories and acceptance criteria?

In Agile development, user stories and acceptance criteria are part of project documentation that describes the product’s vision and requirements.

A user story is a short, simple description of a product feature from the perspective of someone who wants to use that feature. User stories define the product backlog in an Agile development workflow. They consist of three parts: a persona of the user the story is being written for, a description of the feature the user requires, and an explanation of the need the feature satisfies.

Here’s an example of a user story:

As a (user) I want a (feature) so that I can (satisfy a need).

What are acceptance criteria?

Acceptance criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or, in the case of system-level functionality, the consuming system. They are formed as a set of statements, each with a clear pass/fail result, that can be measured and satisfy both functional and non-functional requirements. Criteria are documented and confirmed before the start of a development iteration, as the team and the client need to agree on what outcomes will meet product requirements.

Writing acceptance criteria is important not only for establishing what the client expects of the product but also for the development process. Naturally, different people see the same problem from different angles. Writing acceptance criteria helps to establish a common understanding between the product owner and the development team with regard to solving a client’s issue. It also helps to form a common view of the functionality you plan to implement.

Who writes acceptance criteria?

At Apriorit, our business analysts (BAs) are in charge of writing acceptance criteria and user stories. Business analysts elicit product requirements from our client, write criteria that will ensure the product satisfies these requirements, and ensure that developers know all they need to start coding.

Why do you need acceptance criteria?

Both user stories and acceptance criteria clearly define an organization’s expectations of their application. If your user stories lack acceptance criteria — or if they’re not clearly defined — you risk expectations diverging from reality.

That’s why acceptance criteria are important: they help you accurately plan the development time and deliver a product that is attractive to end users.

• Shared understanding of software. Acceptance criteria create the same image of the product for all parties working on it. They inform the development team about exactly what conditions must be met and ensure the client knows what to expect from the application.
• Improved user experience. As acceptance criteria are written from the end user’s point of view, they help the development team design software that is easy to understand and use. 
• Streamlined acceptance testing. Acceptance criteria are the foundation of user story acceptance testing. Every acceptance criterion should be tested independently and have clear scenarios for success or failure.
• Accurate development planning. Acceptance criteria allow you to distribute user stories across tasks so they can be properly assessed and scheduled. They also help developers and QA engineers assess each task and provide precise estimates.

To ensure such benefits, business analysts can choose the format of acceptance criteria that best fits their project. In the next section, we overview key types and examples of acceptance criteria.

What are types of acceptance criteria?

Based on the nature of their project and the preferences of the client and developers, BAs can use one of the following types of acceptance criteria:

1. Scenario-oriented
2. Rule-oriented
3. Custom 

1. Scenario-oriented

This type of acceptance criteria is presented as a scenario and illustrates each criterion. Scenario-oriented acceptance criteria allow Agile teams to fulfill requirements and use scripts for manual and automated acceptance testing. Business analysts usually rely on Gherkin-style or use case style formatting for scenario-oriented criteria. Let’s take a look at a Gherkin-style example:

User story: As a user, I want to be able to register in the application using my email as a login.

Acceptance criteria:

GIVEN the user opens the registration form

WHEN the user enters their email

AND enters the password

AND confirms the password

AND clicks Register

THEN the system checks entered data

WHEN the email is unique

AND the passwords match

AND the password meets the requirements (8 symbols minimum, at least one special symbol)

THEN the system creates a user record with the Unverified status

AND sends a confirmation email to the user.

Here’s the same acceptance criteria with use case style formatting:

Normal flow

1. The user opens the registration form.
2. The user enters the following values:
   1. Email
   2. Password (8 symbols minimum, at least one special symbol)
   3. Password confirmation
3. The user clicks Register.
4. The system checks that the entered data is valid.
5. The system creates a user record with the Unverified status.
6. The system sends a confirmation email to the user.

Exceptions:

If the passwords do not match, the system displays the corresponding notification.

If the password doesn’t meet the requirements, the system displays the corresponding notification.

If the email is not unique, the system asks the user to restore their password.

2. Rule-oriented 

In contrast to scenario-based criteria, rule-based criteria are presented as a set of rules that describe system behavior. This is the most common way of presenting acceptance criteria, which BAs use when there’s no need to write a criterion as a scenario.

Let’s take a look at an example:

User story. As a security specialist, I want to get an alert when a user tries accessing a suspicious site so that we can avoid security breaches.

Acceptance criteria:

• The system has a new alert type with the following characteristics:
  • Type: Web
  • Name: Suspicious site
  • Severity: High
• The security specialist can define a list of suspicious sites manually in the alert settings.
• An alert is triggered when one of these sites is opened in a supported browser (see the general requirements document).
• An alert is triggered when the site address is typed manually or the user is redirected to the site by a link.
• The alert can be sent as an email, SMS, or push notification depending on the alert settings (see the Alert Notification epic).
• The alert is displayed in the alert report and on the alert dashboard.

3. Custom

Since the key requirement to writing acceptance criteria is making them easy to understand for stakeholders, business analysts can adjust common formats or even create their own. Some development teams prefer working with acceptance criteria structured as test cases, statements, or event–response pairs.

A BA can use any format as long as it conveys the essence and importance of acceptance criteria. Before adding a custom format to project documentation, it’s best to ensure that this format is convenient and clear for the client and everyone in the development and QA teams.

Let’s examine how to write acceptance criteria of any type to ensure their quality.

How to write acceptance criteria: Apriorit tips 

The main challenge of writing good acceptance criteria is to balance detail and broadness. Project documentation has to be clear and concise but not restrictive. At Apriorit, business analysts use the following practices when writing quality acceptance criteria:

Prepare criteria before the iteration starts. Developers need to decide on technical solutions based on acceptance criteria, and criteria should be agreed beforehand. A business analyst should finish writing and discussing acceptance criteria for tasks in the sprint before the sprint starts. Changing acceptance criteria during development will force the team to rework some of the code they’ve already written and conduct additional testing sessions.

Elicit all details of a user story. Broad acceptance criteria make a user story vague, which may lead to incorrect implementation of the client’s requirements. Effective acceptance criteria must clearly outline the scope of work so that developers can properly plan and estimate their efforts. At the same time, acceptance criteria shouldn’t be too specific and narrow in order to give developers freedom to come up with their own solutions.

Use writing best practices. The best way to write acceptance criteria and make them clear for the team is to follow acceptance criteria writing best practices. Following these best practices allows for clearly conveying the client’s ideas. For example, BAs should: 

• avoid excessive use of the passive voice
• use nouns instead of pronouns whenever possible
• avoid over-using conjunctions and comparisons
• use positive sentence structures

Avoid technical details. Acceptance criteria should only indicate the direction for development and not the means of getting there, unless such requirements are specifically stated by a client. They should be understandable for anyone, including people without a technical background. For example, it’s enough to write “All user actions must be logged” instead of “All user actions must be logged in an XML 1.1 file,” as developers might find a more suitable way to store logs and a business representative might not know what XML 1.1 is and why it should be used.

Write achievable criteria. Effective acceptance criteria define expectations of the final product. These expectations must be documented so that all criteria are reasonable and testable. BA analysts constantly communicate with the client and development team to find a compromise between what is wanted and what is possible.

For example, if the customer requests that the app work on any device (which cannot be guaranteed and achieved), a BA can propose a compromise, listing the most popular device models and operating systems. This way, developers can plan their work realistically and deliver the product that their client expects.

Discuss acceptance criteria with the team. Discussing acceptance criteria with all interested parties before the start of development helps to achieve several goals: ensure that acceptance criteria reflect the goals of user stories, clarify the client’s product vision, catch any inconsistencies in documentation, and clear up any confusion within the development team. Such discussions can help developers estimate tasks precisely, avoid rework of already written code, and deliver exactly the product the client expects.

Conclusion

Making sure your project has relevant and effective acceptance criteria increases your chances to deliver an efficient product that satisfies the client. But to define exact development estimates and ensure users will accept your software, you need a professional business analyst.

Consider outsourcing business analysis to experienced specialists who understand all the nuances of your product vision and can clearly communicate them to the development team.

Apriorit’s business analysts create acceptance criteria for all our Agile projects. They discuss criteria with our clients, analyze them to create a definitive picture of the product, and answer the development team’s questions about the criteria.