Acceptance Criteria Basics: What Is it and How to Use It [Templates Included]

Clear communication between clients and developers is the key to success. Vague ideas like “I want an app like Instagram” tell developers nothing and lead to misunderstandings. Acceptance criteria and user stories are designed to keep clients, developers, and the rest of the team on the same page to eliminate ambiguities and carefully transfer the idea.

In this article, we’ll cover the following topics in detail:

It’s worth noting that acceptance criteria are closely related to user stories. They help to shape product and tech requirements and eliminate misunderstandings between clients and team members.

We’ll show you both the user story and acceptance criteria example to make things clearer. Let’s start defining these terms with the user story.

A user story in software development is a term that means the general explanation of a feature written from the user’s perspective. User stories are rather short and refer to one function or feature of the app. Besides that, a user story is a perfect tool for Business Analysts that lets them explain to developers what must be done and why in a simple language.

This works in both ways since the user story helps explain to the product owner what’s planned to implement within the owner's ideas and requirements. In a nutshell, it’s an established way of communication between business and software developers.

A traditional user story looks like this:

As a /user role/ I want to /feature to be completed/ so I can /value of this feature/

If we add some context to that example, it’ll look like this:

As a telehealth patient, I want to see the list of appointments so I can see the doctor remotely.

Now that we’ve figured out what a user story is, it's time to take a closer look at the definition of acceptance criteria and how these two are interconnected.

Acceptance criteria is a list of requirements created to ensure that a user story is completed according to tech requirements. It must cover all scenarios, both successful and not. Clearly and briefly written acceptance criteria facilitate communication with the development team and prevent misunderstandings that can negatively impact the development.

The traditional format of acceptance criteria looks like this:

I have a precondition, and when I perform an action, I expect a certain result.

Let’s add some context to that: the user is chatting with the physician and should be able to share media files and documents.

• When the user clicks on the clip button, a small window appears where the users can choose what exactly they want to send: a photo, video, audio file, or document.
• When clicking for the first time, the app must request permission to access media files. This request must appear until the user gives permission.

The differences between user stories and acceptance criteria are that user stories define the main purpose of a feature, while the acceptance criteria determine what tech parameters developers need to meet to implement that user story.

Acceptance criteria is a vital part of the development process as it aims to fulfill the following goals:

• Find common ground. The development team and the client always remain on the same page. Developers understand what functionality they must deliver, while the client knows what to expect from the final product.
• Facilitate estimation. Clearly written acceptance criteria help easily convert user stories into tasks for developers and accurately calculate development time.
• Simplify testing. When all user stories are documented, it’s much easier to test the app to see if the feature works as intended.

Now that we've covered examples of user stories and acceptance criteria, it's time to discuss types of acceptance criteria.

Before moving to the acceptance criteria examples for user stories, it's worth noting that you can write acceptance criteria differently. There are two common ways: scenario-oriented and rule-oriented.

A scenario-oriented option is often called GWT or Given/When/Then. This acronym defines the structure of acceptance criteria that includes three main parts:

• Given precondition
• When I do this action or interaction
• Then I expect this result
• And which is a linking part for three previous statements

Since this approach comes from BDD (or Behavior-Driven Development), it greatly simplifies the QA process as thanks to the first-person structure of this acceptance criteria, QA engineers can easily write test cases thanks to the pre-described system’s behaviour. They can see at what point the testing of a feature begins and when it ends.

Each scenario-oriented criteria has the following parts:

• Scenario. It’s a name of behavior described in acceptance criteria.
• Given. It’s a start point of the scenario.
• When. It stands for action that the user makes.
• Then. The result of the previous action.
• And. Linking part for continuing previous three parts.

This sequence may look confusing, but things get clearer much faster when implemented into a real-life acceptance criteria example.

User story: As a Guest, I want to be able to sign up via Google account, so I can register my account quick

Scenario #1: Successful Sign up with Google account

• Given: Guest navigates to the Sign up page.
• When: Guest clicks on “Sign up with Google Account” button
• Then: Google Sign up web view opens
• Then: Guest enters his valid Google Account credentials
• Then: Profile is created with fetched email from Google account
• And: He navigates to the “Complete profile” page

Scenario #2: User with this email has already existed

• Given: Guest navigates to the Sign up page.
• When: Guest clicks on “Sign up with Google Account” button
• Then: Google Sign up web view opens
• Then: Guest enters his valid Google Account credentials
• Then: Account with fetched email is already exists in database
• And: Guest sees the error “Account with this email has already exists.”

This type slightly differs from scenario-oriented and can replace GWT type in some cases. Rule-oriented acceptance criteria will be useful when:

• Development team doesn’t need precise test scenarios.
• There’s a need to describe software design.
• Given user stories describe the system functionality level, which needs another QA approach.

The name of this approach speaks for itself. You have a set of strict rules you can use to build specific scenarios in the future. When writing rule-oriented acceptance criteria, you don't need to worry about any form, sequence, and so on. All you need to do is make a bulleted list of rules.

Rules:

1. The “Chat” contains the “Send voice message” button.
2. User is able to hold down the button to record an audio message.
3. While users are recording audio, they’re able to see the incrementing time of recording in seconds.
4. User is able to slide up for hands-free audio message recording.
5. User is able to slide left to cancel recording.
6. The voice message will be sent when the user releases the hold down button.
7. Sent voice message contains a play button.
8. By tapping on the Play button, the user is able to listen to the voice message.
9. By tapping on the Pause button, the voice message should be paused.
10. Pause/Play button should be changed by the Play/Pause button.
11. If video is paused the tap on play will continue the voice message playing from the moment it paused.

Acceptance criteria can be written both by the client and a software development company’s staff. If a client turns to a software development company with ready-made criteria, it passes a strict check by company representatives. During this process, criteria are checked to exclude all logical errors and technical constraints that could interfere with further development processes. However, this approach requires the client to have some experience in software development and writing technical documentation.

If the client doesn’t have any criteria, a software development company can create them from scratch. This task falls on the shoulders of two specialists: a Business Analyst and a Quality Assurance engineer that check all requirements. The creation process takes place long before the start of development so that the client can approve the prepared acceptance criteria and the whole team can proceed to the next stage of development.

It may have seemed to you that acceptance criteria are quite simple to write, and it doesn’t take much time. However, this statement is wrong. Before you start writing your own criteria, you should be aware of some strict requirements that all acceptance criteria documents must meet. These requirements are applicable to any type of criteria.

• It must be testable. This is one of the most important requirements because it determines whether QA engineers can test the criteria or not. They should clearly see the definition of done, and beyond that, there must be no interpretation. Testing should always have a clear answer: test passed or test failed.
• It must be clear and concise. Always keep in mind that all the criteria you write into documentation should be as clear as possible and shouldn’t raise additional questions to clarify any details.
• It must provide a user perspective. Acceptance criteria are written from the end user’s perspective and shouldn’t go beyond the real user experience.

In order to make your criteria fully meet these requirements, follow our tips that’ll help you make no mistakes during criteria creation.

Acceptance criteria can’t be written at the beginning, in the middle, and certainly not at the end of the development process. All criteria are documented at the early stages. This approach helps developers immediately grasp the requirements that must be met and use those requirements later to plan the development process.

In an eagerness to make the criteria as clear as possible, you can make them too specific, thereby leaving developers no freedom for maneuver. To avoid this mistake, remember that the acceptance criteria should express intent, not the final solution. Also, by creating too narrow criteria, you may accidentally not consider some user actions that may be important.

It’s not recommended to overload the acceptance criteria with functionality. The more detailed the requirements, the higher the chance that developers will simply get bogged down in a huge number of small tasks that need to be solved. The criteria should contain a reasonable minimum amount of functionality.

Too broad criteria can make the user story very vague. Well-written criteria should help you easily identify the amount of work to be done and estimate the time required for development accurately.

You shouldn’t include various technical details in the acceptance criteria if you want to keep them transparent and understandable for everyone who’ll become familiar with them. Some managers may not have technical experience or knowledge, making it difficult to analyze the criteria.

While many problems can be solved in several ways, you should find common ground. Whether you work with an in-house team or software development service vendor, everyone involved must carefully analyze your criteria and confirm that all stakeholders agree with each line. After that, you can proceed to the next step of the software development process.

Now it’s time to show you the real acceptance criteria example. We’ve prepared a part of the project specification made for a Tinder-like app. This document includes user stories and acceptance criteria for sign in and sign up features.

Writing criteria is a responsible process that requires some preparation. On our behalf, we can provide a template that suits the writing of scenario-oriented and rule-oriented acceptance criteria.