Blog / Development / software documentation

The Ins and Outs of Acceptance Criteria

  • Rating — 5 (4 voices)
  • by Ivanna Denys
  • Updated on May 14, 2019
  • Read —
    7-8 minutes
people with checklist

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.

  1. Specifications, epics, and user stories
  2. What are the acceptance criteria?
  3. Key functions of acceptance criteria
  4. Who creates acceptance criteria?
  5. 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.

acceptance criteria

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.

consensusHelp 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.

clockAllow 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.

checklistDefine 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.

testingServe 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?

Ivanna is a Content Marketing Manager of GBKSOFT passionate about tech advancements, marketing, and startups. Her dream is to make the virtual world a better place with the help of a written word.

Leave a comment

Leave a Reply

Related services

Similar Blog Articles


Epics vs User Stories: the Key Difference and Examples

If you have ever developed any software or just plan to do this, you’ve probably heard the words “epic” and “user story”. There are also good chances that you’ve seen epics and user stories in a budget estimation received from IT outsourcing company, in case you’ve ever requested such. This is because both terms are...

Rating — 4.2 (16 voices)
technical documents


Types of Technical Documentation for Software Development

Software technical documentation is an essential part of every development project and it’s crucial to have it in place to achieve the expected results. Documents created at various stages of software development life cycle (SDLC) bring different benefits to different participants who take part in the process (e.g. clients, CTOs, developers), but they are equally...

Rating — 4.7 (38 voices)


All articles Business Company News Development Marketing StartUp App Ideas UI and Design

People are talking about

You've got
a project in mind

What's next?

Send us a message with a brief description of your project.
Our expert team will review it and get back to you within one business day with free consultation and to discuss the next steps.


I think they do great work. I haven’t yet given them something that they were unable to do. Great
I’ve been using GBK Soft for the past 3 years and they have been great. Communication is unparalleled to other app development companies. I’ve continued to return to them to improve my iOS app countless times and I will continue to do so in the future. I highly recommend this company! Improve
Gireesh, USA
One word...EXCELLENT.
Very well thought out and articulate communication. Clear milestones, deadlines and fast work.Patience. Infinite patience. No shortcuts. Even if the client is being careless (me). The best part...always solving problems with great original ideas, especially with this strange project where we are making up new words every day!
App Futura Top App Development CompaniesGood FirmsClutchAwwwards