Blog / Tech / software documentation

The Ins and Outs of Acceptance Criteria

  • Rating — 4.9 (9 votes)
  • by Ivanna
  • Updated on March 22, 2021
  • Read —
    12-13 minutes

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.

Are you looking for more information about Software Development Documentation? Please, read the article:

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.

Want to know more about Epics and User Stories? Please, read this article:

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.

acceptance criteria

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.

Need help with acceptance crateria for software project ?

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.

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

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

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

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 approvals 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 functionality. But if you spray on the description of all the small details, there is a risk that the development team will get stuck on 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.
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.

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.

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.

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
  • It is vital to write Acceptance Criteria from the user’s point of view. This way, you will have the opportunity to look at the problem from the customer’s perspective, namely the real user experience. After all, it is for users that you create a product and solve their problems.
  • The criteria must be precise, concise, and understandable. Every person involved in the product development process needs to understand your Acceptance Criteria; they don’t make sense if your developers can’t understand them. If there are points that may raise questions, it is better to say everything additionally.
  • Acceptance Criteria is not about “how to do.” It’s about “what we create.” Like User Story, Acceptance Criteria are not tasks. They are more of a technology for communicating about User Story.
  • Well-written acceptance criteria are clear and understandable to all stakeholders and professionals involved in the user story. An essential indicator of well-written acceptance criteria is the simple and understandable language in which they are written. It is vital to avoid specific terms, abbreviations, and slang that can lead to misunderstandings.

    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?

    Ivanna 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


    All articles Business Company News Marketing Tips Our Awards StartUp App Ideas Tech Tech News Review UI and Design
    GBKSOFT Team photo
    A-mazed to meet you!
    We are GBKSOFT software company.
    Thanks a lot for reading your blog
    Since 2011 we create ambitious software projects from scratch.

    How can we help you?

    • Indicating scope, timeframes, or business challenges would allow us to provide a better response
    • Our expert team will get back to you within 24h for free consultation
    • All information provided is kept confidential and under NDA

    Looking forward to your message!