It’s hard to argue that the ultimate results of any project heavily depend on how well all the parties and team members understand each other’s needs and wants. Software development is not an exception. Yet, the creation of technology solutions is usually a rather complex process that often involves people with different backgrounds (i.e. CEO, CTO, tech specialists, marketers, etc.).
So how do all these people who speak different professional languages agree on a common vision of a product? And what exactly do clients mean when say that they need stunning solutions to make their businesses work better?
The answer lies in acceptance criteria and we will discuss them in detail in this post. What are the acceptance criteria? Who writes them? Who needs them and, more importantly, why? We will also provide you with some examples so you can better understand how the acceptance criteria may look like in practice and capture their vital role in the project success. But let’s start from the basics and take a brief look at other essential components of specifications.
- Specifications, epics, and user stories
- What are the acceptance criteria?
- Key functions of acceptance criteria
- Who creates acceptance criteria?
- When must acceptance criteria be defined?
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 requirements to it. Specifically, it is used to define how the system is meant to behave and what functionality is required to satisfy users’ needs. In addition, specs usually contain some non-functional requirements such as security, performance parameters, etc.
Looking for more information about software development documentation? Read this article:Types of Software Development Documentation
SRS 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 in order to allow all the participants of the development process to grasp the big picture and enable discussion of 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, so that I can have a new password for my account.
Want to know more about epics and user stories? Read this article:Epics vs User Stories: the Key Difference and Examples
However, as you may see, the above statement lacks many details and, thus, creates a 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 are the conditions which a specific user story must satisfy to be marked as “Done”. You may think of them as a checklist that helps to verify if a coding team built the right feature and whether such a feature is completed correctly.
There are no templates of acceptance criteria. Neither would you find an exhaustive list of requirements which should be covered by acceptance criteria associated with a particular user story. This 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 and 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:
- 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 8 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 main task, i.e. show what exactly should be in place to make the system work as it’s supposed to.
Key functions of acceptance criteria
So why are acceptance criteria important? Basically, 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 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 single vision of a product to everyone who takes part 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. This helps a development team correctly estimate the work in terms of time and costs. In addition, 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 the clear pass and fail results. That’s why quality assurance team use 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. This is required in order to make sure 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 important things to consider. First of all, acceptance criteria must be expressed in a simple and not technical language. This is because, as we already mentioned, people with no technical background will use them as well. And, secondly, acceptance criteria should describe what to build rather than how to build it.
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 huge 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 a quite negative outcome for both a client and a coding team.
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, basically, all participants of the project are allowed to make their inputs. In practice, the exact set and format of acceptance criteria depend on the specifics of a project, 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 programmers to make it a reality?