It’s hard to argue that any project’s ultimate results heavily depend on how well all the parties and team members understand each other’s needs and wants. Software development is not an exception. Creating technology solutions is usually a somewhat complicated process that often involves people with different backgrounds (i.e., CEO, CTO, tech specialists, marketers, etc.).
How do all these people who speak different professional languages agree on a shared vision of a product? And what exactly do clients mean when they say they need stunning solutions to make their businesses work better?
The answer lies in the acceptance criteria, and we will discuss them in detail in this post. What are the acceptance criteria? Who writes them, and Who needs them? The most crucial question. Why? We will also provide you with some examples to better understand how the acceptance criteria may look like in practice and capture their vital role in the project’s success. But let’s start from the basics and take a brief look at other essential components of specifications.
Specifications, epics, and user stories
Software Requirements Specifications or simply “SRS” or “specs” is a document that describes all the features of a solution and its requirements. Specifically, it is used to define how the system is meant to behave and what functionality is required to satisfy users’ needs. Also, specs usually contain some non-functional requirements such as security, performance parameters, etc.
SRS (Software Requirements Specifications) often consists of epics and user stories. Simply put, an epic is one big piece of product functionality. For example, registration and user profiles are epics. Specs are divided into epics to allow all the development process participants to grasp the big picture and discuss a product on a high level (for example, between tech leads and CEOs).
The specific tasks within an epic are written in the form of user stories. These are, for instance, “Sign-up with e-mail,” “Log out,” etc. As a rule of thumb, the following wording is used to create a user story:
As a [type of user], I want to [action] so that [outcome].
So, for instance, here is a user story to describe a task for a system when a user forgot his or her password:
As an unauthorized user, I want to have an opportunity to recover my password using my email to have a new password for my account.
However, as you may see, the above statement lacks many details and creates room for ambiguity. That’s why user stories usually go with a set of acceptance criteria. Let’s cover them next.
(In this video, you will learn about Agile User Stories and Acceptance Criteria.)
What are the Acceptance Criteria?
In short, acceptance criteria are the conditions that a specific user story must satisfy to be marked as “Done.” You may think of them as a checklist that helps verify if a coding team built the right feature and whether it is completed correctly.
Acceptance Criteria can include details such as:
- User experience;
- Impact of the current User Story on existing functionality;
- Key performance metric (e.g., speed);
- What the User Story should do.
To figure out the minimum set of actions your team needs to develop, you must thoroughly understand the function and its complexity. If the feature is involved, it will be essential for you to write as many detailed Acceptance Criteria as possible to help your team avoid confusion.
There are no templates of acceptance criteria. Neither would you find an exhaustive list of requirements that should be covered by acceptance criteria associated with a particular user story. It is because every product is unique and, thus, everything depends on the client’s demands and specifics of the system to be developed.
For instance, acceptance criteria may describe the functionality, expected level of performance, constraints, restrictions, interaction with other features, etc. Let’s say a coding team needs to work on a “Reset password” user story. In such a case, the acceptance criteria might be the following:
- The user will need to enter a new password.
- The new password must differ from the previously used password.
- The new password must contain at least eight characters.
- The new password must not contain braces.
The above example is, of course, oversimplified. In practice, acceptance criteria may be written in different formats (for instance, bullet points or a table or scenarios). The only requirement is that they should perform their primary task, i.e., show what exactly should be in place to make the system work as it’s supposed to.
Types of acceptance criteria
Now that we have further defined the acceptance criteria and figured out what functions they perform let’s talk about their types. There are three main types of acceptance criteria:
- scenario-oriented (drawn up as scenarios illustrating each criterion);
- rule-oriented (documented as a list);
- custom criteria (can be presented as plain text or table).
Scenario-oriented acceptance criteria
Many teams that work with the Agile methodology prefer the scenario-oriented type. This approach helps to overcome the requirements and involves scripting in manual and automated acceptance tests. This approach was inherited from behavior-driven development (BDD).
A popular approach to writing acceptance criteria is the scenario-oriented Given / When / Then approach. This format is a structured approach for many test environments such as Cucumber. The Given-When-Then pattern allows you to automate a test to determine if a requirement is developed or not.
You can describe Acceptance Criteria in paragraphs or immediately in the Given-When-Then format:
- Given is a clause that describes the state before the user entered the script.
- When – something happens: the user takes some action.
- Then – a description of how the system responds to user actions.
For example, if you create a website with two types of users – registered users and guests – the acceptance criteria will be written for the user story that defines the login function for the logged out user:
Scenario: System user signs in with valid credentials
“Given I’m a logged-out system user
and I’m on the Sign-In page
When I fill in the “Username” and “Pa
password” fields with my authentication credentials
and I click the Sign-In button
Then the system signs me in”
Given / When / Then helps reduce the time it takes to write test cases because when writing criteria, we describe the system’s behavior in advance.
Rule-based acceptence criteria
- Unfortunately, the Given / When / Then structure is not always suitable for writing acceptance criteria. For example:
- You are working with user stories that describe system-level functionality that requires different quality assurance methods.
- The target audience for acceptance criteria does not need the exact details of the test cases.
- Suppose you need a description of the design and user experience limitations of a function. Developers may be missing many important details.
In cases where Given / When / Then does not suit you, you can use rule-based AC format. A rule-based form assumes a set of rules that describe the behavior of a system. Based on these rules, you can write specific scripts.
Typically, criteria generated using this form look like a simple bulleted list. For example:
As a logged-out user
I want to be able to sign in to a website
So that I can find access to my personal profile
Key functions of acceptance criteria
So why are acceptance criteria critical? All participants of the development process take advantage of acceptance criteria in some way. So let’s take a look at how acceptance criteria contribute to the project’s success.
Help reach consensus
As mentioned, software development usually involves people having different backgrounds. By formalizing the client’s expectations, acceptance criteria allow for sharing a product’s single vision to everyone in the project. They determine the set of requirements that is sufficient to build an envisioned and working solution.
Allow for accurate estimation
Acceptance criteria show how the product should function in great detail. It helps a development team correctly estimate the work in terms of time and costs. Also, acceptance criteria allow programmers to plan the process in the most efficient way.
Define the minimum conditions for success
A coding team relies on acceptance criteria to determine a detailed must-have feature scope. In other words, acceptance criteria constitute a list of minimum requirements for a user story to be considered “done.” Without them, there would be too much room for uncertainty, and programmers would have a hard time figuring out what exactly they have to build.
Serve as a basis for testing
All acceptance should be testable, i.e., have a precise pass and fail results. That’s why the quality assurance team uses them to check if a system works as it’s meant to work. On top of that, acceptance criteria come in handy when testing specialists write autotests.
Who creates acceptance criteria?
As a rule, acceptance criteria are written by a product owner or business analyst (depending on the chosen project management methodology). However, all participants of the development process, including clients, can contribute to their creation.
If a client documents acceptance criteria, they should be reviewed by tech specialists. It is required to ensure that there are no constraints from the technical perspective, and all the requirements can be implemented in practice.
Either way, a development team has an opportunity to make some inputs to acceptance criteria during the discussion of a particular user story. Yet, there are two essential things to consider. First of all, acceptance criteria must be expressed in a simple and not technical language. Because, as we already mentioned, people with no technical background will use them. And, secondly, acceptance criteria should describe what to build rather than how to make it.
Significant challenges and mistakes in writing acceptance criteria
At first glance, it may seem to you that there is nothing complicated in writing acceptance criteria, but it is not. When, in practice, teams start working on them, they face difficulties. Let’s take a look at methods to help avoid future problems.
When must Acceptance Criteria be defined?
All acceptance criteria must be defined before the development of the relevant functionality starts. No acceptance criteria could be added after a coding team begins to work on a particular user story. And this is a crucial aspect that has a considerable impact on the ultimate success of a project.
In case acceptance criteria were not specified in advance, they would likely describe what programmers built-in reality rather than an envisioned product that fits clients’ requirements. As a result, a deliverable would not meet the expectations, and it is an entirely negative outcome for both a client and a coding team.
- User experience
- Impact of the current User Story on existing functionality
- Key performance metric (e.g., speed)
- What the User Story should do
A bottom line
Acceptance criteria play an important role in software development. In particular, they help all sides of a project (i.e., clients, partners, tech team, marketers, etc.) get a single vision of a product and keep staying on the same page all the way through. As a result, programmers know exactly what to build, and clients receive a decent solution that meets their expectations at the end of the day.
There are no strict rules on how to write acceptance criteria, and all participants of the project are allowed to make their inputs. In practice, the same set and format of acceptance criteria depend on a project’s specifics, features of a product to be developed, project management methodology, and other factors.
Have an idea of an app for your business and looking for developers to make it a reality?