Table of Contents
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 product vision? And what exactly do clients mean when they say they need stunning solutions to make their businesses work better?
The answer lies in the clear acceptance criteria, and we will discuss them in detail in this blog post. What are the acceptance criteria? Who writes them, and who needs them? And the most crucial question – why? We will provide you with some examples to better understand how the effective 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 Story
Software Requirements Specifications or simply “SRS” or “specs” is a document that describes all the product features and requirements. Specifically, it is used to define how the system is meant to operate and what functionality is required to satisfy user expectations. Also, specs usually contain some non-functional requirements such as security, performance parameters, etc.
Software development documentation
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 that allow everyone involved to grasp the big picture and discuss high-level product details (for example, between tech leads and CEOs).
The specific tasks within an epic are written in the form of user stories. they describe the required functionality from the user’s perspective. These are, for instance, “Sign-up with e-mail,” “Log out,” etc. As a rule of thumb, the following wording is used to create one user story:
As a [type of user], I want to [action] so that [outcome].
So 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.
Epics, User Story, and Initiatives
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.
What are the acceptance criteria?
In short, acceptance criteria establish the conditions that a specific user story must satisfy to be considered as completed, 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.
Effective acceptance Criteria can include details such as:
- User experience;
- Impact of the current User Story on the existing functionality;
- Key performance metrics (e.g., speed);
- What the User Story should do.
To figure out the minimum set of actions your team needs to take, you must thoroughly understand the complexity of a certain function. If a new feature is involved, it will be essential for you to write as many detailed Acceptance Criteria as possible to help development teams 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. Every product is unique, 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 oversimplified, of course. 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 cope with their primary task, i.e., show what exactly should be in place to make the system work as intended.
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 variety. 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 a 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 manual and automated acceptance testing. This approach was inherited from behavior-driven development (BDD).
A popular approach to well written 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 requirements for the logged out user:
Example of well defined acceptance criteria: User story – Sign Up
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 acceptance 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 does not provide enough exact details for testing acceptance criteria.
- 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 the 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 bullet 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 them 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 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.
Importance of acceptance criteria
As we have already figured out, acceptance criteria actually determine the desired outcome of a user story, show when it is completed, and is ready to be tested by QA specialists. If you still are not 100% convinced why acceptance criteria are vital, we would like to count some reasons that highlight the importance of acceptance criteria and prove that they influence the final outcome:
- Manage expectations of the function that the user story was created for;
- Make the project scope and requirements accurate and clear;
- Help to create the needed testing criteria to figure out if the function will fail or pass.
Who creates acceptance criteria?
As a rule, acceptance criteria are written by a product owner or a business analyst (depending on the chosen project management methodology). However, all participants of the development process, including clients, can contribute.
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.
The 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.
Examples of acceptance criteria
Here you can find several more examples of how acceptance criteria actually look like as a component of a user story.
How to write acceptance criteria?
And of course, to make life easier, we will provide you some tips to create correct and convenient acceptance criteria from our Business Analyst:
- always write a scenario name for each acceptance criteria, it won’t take too much time but will bring your team a lot of benefits. First of all, the list of points for the review meeting will be ready. Secondly, in case you forgot how to act in a specific case, you can search for the correct answer by the scenario name.use “AND”, “OR” and “BUT” to make no ambiguity to your acceptance criteria and provide more clear steps for the dev team
- use simple English to be sure all the specs users will fully understand you
- draw a high-level diagram with positive and negative scenarios not to miss something and to visualize the process to everyone.
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.
Criteria documentation
Before starting development, you need to document the acceptance criteria to understand the customer’s needs clearly. Start by defining a small number of user stories to fill in the backlogs for the first sprints, once agreed by both parties. After all the edits and final approval of the documented acceptance criteria, the developers begin to plan the technical process.
Achievable criteria
Properly written ACs should primarily define a reasonable minimum amount of desired functionality. But if you spray on the description of all the small details, there is a risk that the development team will get stuck with many small tasks.
Narrow criteria
If ACs are too narrowly focused, developers will not move away from them to achieve the desired result. It is important to remember that acceptance criteria are intentional rather than rigid guidelines
Mutual agreement
The team and stakeholders may have different visions of how to solve the same problem. Therefore, everyone involved in the product development process must confirm that they understand and agree with all ACs.
Create a test AC
This approach will allow testers to ensure that all requirements are met; otherwise, it will be difficult to understand if the user story is complete.
Overly broad acceptance criteria make the user’s story vague. Correctly written ACs, as we have said, must define the scope of work so that developers accurately allocate time and effort for development.
When must Acceptance Criteria be defined?
All acceptance criteria must be defined before development 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 build currently without any previously defined plan. It is unlikely the developers’ actions will 100% fit the client`s 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.
Checklist: components of acceptance criteria
Acceptance criteria are tasked to provide developers with a clear understanding of how this part of the solution`s functionality should look, what aims it has, and what value it brings to users. We covered the core tips to help you make your acceptance criteria complete, valuable, and easy to understand for the development team and the stakeholders as well. Hence, acceptance criteria should include the following:
- Think of real user experience and behavior to ensure that it will be valuable for users;
- Define how a particular user story influences the solution`s functionality;
- Set the limit to the number of details which acceptance criteria must include;
- The more accurately the acceptance criteria are defined, the more accurate estimation the development team will provide, so the details still matter;
- Identify key performance metrics;
- Determine what a particular user story provides;
- Write acceptance criteria considering the customers` views and expectations;
- Make sure the criteria are accurate and clear for the stakeholders and development team, don`t use vague words and phrases.
The 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 stay 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.
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.
