Acceptance criteria: Definition, Types and Best Practices (2023)

The quality and success of any project require excellent communication between the client and the development team. If clients are vague with descriptions of what they need, developers will have a hard time making a good product. More than anybody, software developers understand how important it is for a client to present their vision for a product clearly. Clients and teams working on the project write user stories to reduce the likelihood or even eliminate misunderstanding.

What are the user stories?

User stories allow anybody, no matter their level of expertise, to describe the functionality of their product using plain English without having to mention any technical details. The great thing about user stories is that they’re easy to write. They’re also essential when you’restarting a development project. Clients can write them on a small piece of paper, while developers usually put them on sticky notes or list them on a whiteboard.

User stories are an excellent way for the development team to brainstorm ideas and decide how a certain software product should look like. They allow clients to get the message of their vision across without having to worry about how it will be done.

Although some people may approach developers with a detailed list of requirements that perfectly describe the functionality of a product, most clients won’t have the technical knowledge to do this. User stories examples were created for those who perhaps don’t know how their software product should work but have a clear understanding of what their customers want.

In most cases, clients will write the majority of the user stories at the beginning of the project. As time passes and developers start working on it, they’ll take over the writing as a way to communicate and build on each other’s ideas. The user story itself is a tool used to spark a conversation between the team members who try to come up with ideas on how to reach a specific goal.

How to write user stories?

There is a simple equation that you can use to write a user story:

As a <type of user>, I want to <be able to do something> so that <some reason>.

As you can see, the format of a user story is very simple and doesn’t leave room for detail. However, this is exactly why it is used. User stories usually consist of 10-15 words, in which you can clearly describe the essence of your product and what you’re trying to accomplish with it.

The first part of the equation describes who the user of your product will be. The second part should clarify the feature you’re building. Meanwhile, the final part should describe exactly why you’re making the feature as well as why you think the customer will want to use it.

(Video) How, What & Why of Acceptance Criteria | acceptance criteria agile | acceptance criteria

Bill Wake, one of the leading specialists in agile software development, created a set of criteria for user stories commonly known asINVEST. As a frequent contributor, he often tells students that following this set of criteria is essential for creating a good user story. The acronym INVEST stands for:

  • Independent– One user story shouldn’t have any inherent dependency on another.
  • Negotiable– User stories should always be used to start a discussion between developers, not to define a fixed workflow.
  • Valuable– Each user story needs to be of value to the customer.
  • Estimable– You should be able to determine how much time you’ll need to develop each user story.
  • Small– A user story needs to be small enough so that it can be finished in as little time as possible.
  • Testable– A user story needs to have the necessary information to make testing realizable.

Now, you might be thinking about why you would even need writing user stories if you could just describe the features you want your product to have. However, know that stories encourage developers to collaborate and brainstorm to come up with the most creative ways to build your product.

But to ensure that the development team understands the true value of your user story, you should set certain acceptance criteria goals. You’ll learn more about that in a minute after you go through some of the most notable practices for creating stories.

Best practices for writing user stories

Writing a user story template is so easy that anyone could do it. However, it can be challenging to write an effective story. Here are some tips for you on how to write user stories, so they work best for your product.

1. Keep your focus on users

You should start writing user stories only after you determine exactly why people would want to use your product. It’s imperative that youknow who your target audience isand why they would be interested in a particular feature before you create a story.

Research your competitors and what their customers say about them. It’s also a good idea to interview users and ask them what they would like to see in a new product or update. Doing this will help you identify every type of customer that will potentially use your product and ensure that they’re satisfied.

2. Refine your user stories

After you write a user story, it doesn’t necessarily mean that your job is done. You’ll still have to discuss it with the development team or other individuals involved in the project. Sometimes a discussion will lead to new ideas, which is when you should determine if there is anything you should change in your user story. Remember that this is a collaborative effort, so don’t be afraid to share any new suggestions to make your product better.

3. Use paper cards

One of the best ways to ensure you have a good brainstorming session with other people working on the project is for each person to work on an idea separately at first. Distribute paper cards among the team and encourage each member to write down an idea for a user story. After everyone is finished writing their ideas, compare them, and try to determine what the best story would be.

(Video) Definition of Done VS Acceptance Criteria | ScrumMastered

4. Make user stories visible

Making a good product requires you to come up with numerous different user stories. To keep track of everything that you and other team members wrote, you should make every user story visible. Write down everything that you came up with on sticky notes and place them on a whiteboard.

Divide them into three categories – stories that are awaiting approval, stories that you’re currently working on, and the ones that are done. If the people working on your project don’t share the same office, make sure they can easily find the stories on your server.

5. Use personas to create user stories

Examine your target group and identify the types of users that are likely to use your product.Create fictional charactersbased on your research to decide which user stories are good. All you need to create personas is to jot down some relevant characteristics and behaviors of your target audience. Divide them into as many categories as possible and try to determine what users in each group are looking for in a product.

Acceptance criteria: Definition, Types and Best Practices (5)

What is acceptance criteria in Agile?

In Agile, acceptance Criteria (AC) is a term used to describe a set of predefined requirements that developers must meet in order to finish working on a particular user story. While the development team is tasked with executing the stories by following the predefined requirements, you will have to define what your acceptance criteria are. Keep in mind that every user story needs to have a unique set of criteria.

If you don’t write good acceptance criteria for user stories, it may yield some unpredictable results when the developers finish your product. It’s worth mentioning that the product owner doesn’t have to be the only one to write acceptance criteria; the development team can also work on them, especially when discussing how they’ll work on user stories.

You need to have clear acceptance criteria to ensure you end up with a product your users will be satisfied with. You can write AC in different formats. Although you have the complete freedom to create your own format, there are two common formats used for creating acceptance criteria. Since they have specific structures, it’s usually a good idea to use one of two common formats to make sure each user story is executed perfectly.

How to write acceptance criteria?

Your first option is to use a scenario-oriented format. There is a process in software engineering known asbehavior-driven development. It describes a process that encourages communication and collaboration between business participants in a software project and the development team.

(Video) How I Write Great User Stories with Strong Acceptance Criteria

The scenario-oriented AC approach is inherited from behavior-driven development and is an excellent way to set guidelines on when developers should begin and end testing a certain feature. If you decide to go with the scenario-oriented AC format, you’ll have to use these statements:

  • Scenario– In the first statement, you’ll have to write the name of the behavior that you’re describing.
  • Given– The second statement refers to the beginning stage of the scenario.
  • When– The third statement involves a particular action that you want the user to make.
  • Then– This is used to describe the outcome of the third statement.
  • And– You can use “And” to continue any statement except “Scenario.”

This can seem a bit confusing at first, but it’s actually quite simple. Here’s an example of how ascenario-oriented formatwould look like on an example:

  1. User story:As a credit cardholder, I want to receive a notification when I have less than $1,000 in my account after making a big deposit so that I don’t overspend.
  2. Scenario:Notification to prevent overspending
  3. Given:The user has opened a bank account
  4. And:The user has received a credit card
  5. When:The user has less than $1,000 after a bigger deposit
  6. Then:The system notifies the user of their balance

The second most common method of writing acceptance criteria is using the rule-oriented format. Depending on your product, it can sometimes be extremely hard or even impossible to use the scenario-oriented format. When you want to clearly convey your message on how the design or user experience of your product should be, it’s best to use the rule-oriented format.

All you have to do is come up with a set of rules on how your product should look like. The rule-oriented format is basically like writing a simple bullet list with all the features you want your product to have. By doing this, you’ll ensure that the development team understands your vision clearly.

Best practices for writing acceptance criteria

There are a few important reasons why you should write user story acceptance criteria. If you were only to provide developers with user stories, you might not end up getting the product you expected. Developers may interpret your user stories in different ways without AC, which may cause conflicting ideas and make collaboration harder.

It can be hard to understand how to actually create acceptance criteria if you never had the opportunity to do it before. In case you don’t have any acceptance criteria examples or any experience writing AC, make it your dissertation topic. This will give you the chance to become a master of agile development before you even get a job in this field, and it will look very impressive on your resume.

Know that there are many professional software developers who offer dissertations services and are open to collaborating with Ph.D. students on topics like acceptance criteria.

Withoutacceptance criteria, you’re basically enabling the development team to decide when a particular story can be marked done. To avoid these problems, you should always set acceptance criteria for your user stories. Here are some of the best practices for writing AC.

(Video) Acceptance Criteria: How to Meet User Expectations

1. Avoid making acceptance criteria too narrow

Understand that developers need to use a lot of creativity in their work. If you make acceptance criteria too narrow, they might not be able to create good features for your product. Remember that AC should not be used to describe a final solution, but rather what your intent is. Allow the development team to execute the user story in different ways by leaving some wiggle room.

2. Make sure the acceptance criteria are testable

The goal of writing acceptance criteria is not to describe how you want a certain feature to be made. The sole purpose of AC is to describe exactly what you want to make. Therefore, you need to make sure the acceptance criteria are testable with a clear Yes/No result. This means that the results of the tests shouldn’t leave any room for interpretation.

3. Make the acceptance criteria concise

The whole point of writing acceptance criteria is to ensure the development team doesn’t misinterpret your requests. With that being said, it’s imperative to make your AC concise. Whenever you’re writing acceptance criteria, try to look at it from an objective standpoint and figure out whether the developers will understand what you’re saying.

The best way to avoid confusion is to simply use short sentences. Don’t use jargon or complex words that can be interpreted in different ways. Know that developers will find it easier to remember short statements. If you keep your AC concise, there’ll be less room for error.

Before the development team starts working, you should first share your ideas with them. Go over everything together to make sure you’re on the same page. Developers should analyze your acceptance criteria and share their interpretations. If you feel the need to clarify something, do it right away to keep confusion to a minimum later on. In some cases, you may even come up with better acceptance criteria after talking to the development team.


Collaboration is extremely important in order for any project to be a success. Although it’s easy to communicate and share ideas with people in your field, it can be challenging to do this with someone with a completely different set of skills.

You may have a keen sense of business and have a good idea of what your users want, but if you don’t have the technical know-how, you’ll have a hard time explaining what you need. This is where user stories come in.

User stories are an excellent tool to work out the technical details of your product with a development team using plain English. Not only do they allow you to express exactly what you want your product to have, but they also encourage collaboration between developers and will likely help them create something better than you expected.

The whole idea behind writing a user story is to break down the desired feature of your product to its most basic elements. To ensure that the development team executes each user story perfectly, you’ll also need to come up with a set of predefined requirements commonly referred to as acceptance criteria.

(Video) What Are User Story Acceptance Criteria?

There are two basic formats for writing acceptance criteria – scenario-oriented and rule-oriented. If you’re unable to use either of these formats for your user stories, you always have the option of making your own custom criteria.

Michael Gorman is a highly skilled freelance writer and proofreader from the UK with deep interests in technology, programming, and software development. He is among the top paper writers in the country and loves spending his free time working with students. Michael loves seeing young people unlock their full potential, which is why he frequently collaborates with them and provides them with assignment help.


What are the types of acceptance criteria? ›

There are 3 main types of acceptance criteria that we outline below.
  • Scenario-Oriented Acceptance Criteria. The scenario-oriented approach is laid out like this: ...
  • Rule-Oriented Acceptance Criteria. ...
  • Custom Formats. ...
  • Defined Pass/Fail Results. ...
  • Concise Criteria. ...
  • Shared Understanding.

How do you write acceptance criteria and best practices examples? ›

Here are a few tips that'll help you write great acceptance criteria: Keep your criteria well-defined so any member of the project team understands the idea you're trying to convey. Keep the criteria realistic and achievable. Define the minimum piece of functionality you're able to deliver and stick to it.

How does Scrum define acceptance criteria? ›

Generally, Scrum acceptance criteria are initiated by the Product Owner with input from the user, customer, or stakeholder. But writing the criteria is not solely the responsibility of the Product Owner. Acceptance criteria should be developed as a joint effort between the development team and the Product Owner.

What are 5 types of criteria? ›

9 Types of Criteria
  • Scores. A minimum score on a standard test that is required to be considered for admissions into a university or college. ...
  • Scoring Structure. A structure for scoring. ...
  • Principles. ...
  • Rules. ...
  • Guidelines. ...
  • Requirements. ...
  • Specifications. ...
  • Algorithms.
29 Jul 2018

What are the 4 types of acceptance testing? ›

Types of acceptance testing include:
  • Alpha & Beta Testing.
  • Contract Acceptance Testing.
  • Regulation Acceptance Testing.
  • Operational Acceptance testing.

What are the types of acceptance criteria in agile? ›

Most agile organizations use one of two formats for their acceptance criteria:
  1. Given/When/Then Acceptance Criteria. The Given/When/Then style of user story requirements is similar to the traditional formatting for user stories themselves. ...
  2. Verification List Acceptance Criteria.
20 Mar 2019

What are the 6 stages of acceptance testing? ›

The 6 Steps of Testing to get to “Final Acceptance”
  • Stage 1: Factory Acceptance Test.
  • Stage 2: Customer Acceptance Test.
  • Stage 3: Site Acceptance Test.
  • Stage 4: Coverage Verification Test.
  • Stage 5: Final System Acceptance Test.
  • Stage 6: Burn In Period.
25 Oct 2012

What is acceptance criteria checklist? ›

What are the Acceptance Criteria? In short, acceptance criteria are 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.

What does the 4 Cs stand for in Scrum? ›

To help the agile and other project managers remember how to best hold people accountable, I like to think of the 4Cs: clarity, commitment, comment, coach. In brief, these are: Clarity. Being clear about what is needed is the first step.

What is acceptance criteria in ITIL? ›

1. The ITIL definition of service acceptance criteria is: A set of criteria used to ensure that a service meets its functionality and. quality requirements and that the service provider is ready to operate the. new service when it has been deployed.

What is the difference between acceptance criteria and definition of done? ›

The difference between DoD and acceptance criteria is in their scope. While the definition of done applies to all your work, acceptance criteria are related to individual pieces of work, including user stories and, in some cases, PBI.

Who is responsible for acceptance criteria? ›

Generally, acceptance criteria are initiated by the product owner or stakeholder. They are written prior to any development of the feature. Their role is to provide guidelines for a business or user-centered perspective. However, writing the criteria is not solely the responsibility of the product owner.

What is Gherkin acceptance criteria? ›

Gherkin is a Domain Specific Language for writing acceptance criteria that has five main statements: Scenario — a label for the behavior you're going to describe. Given — the beginning state of the scenario. When — a specific action that the user takes. Then — a testable outcome, usually caused by the action in When.

What makes a good acceptance criteria? ›

Acceptance criteria should contain a customer-centric focus that enables development teams to ensure expected functionality throughout the coding process. Ideally, the product team should define that acceptance criteria within the user story before the development team gets involved.

What are the four types of criteria? ›

The four criterion types focus on evaluating content, process, quality, and impact.
For example:
  • Did my story entertain my readers?
  • Was my diagram informative?
  • Could the visitor find their way using my map?
  • Did I find answers to my research questions?
  • Was my argument persuasive?
  • Was the problem satisfactorily solved?
2 Mar 2016

What are the 8 criteria? ›

The tool uses these eight criteria: expected benefit, expected cost, the cost of not implementing the option, risk, ease of implementation, motivation, time needed for implementation, and the term to payoff.

What are the types of criteria? ›

There are two types of criteria you can use; specific and generic. Specific criteria can be answered with a simple yes, no or maybe.

What are the four 4 types of systems tests? ›

There are four main stages of testing that need to be completed before a program can be cleared for use: unit testing, integration testing, system testing, and acceptance testing.

What are 3 types of testing and 3 types of testing environments? ›

What Are the Different Types of Testing Environments?
  • Performance Testing Environment. ...
  • System Integration Testing (SIT) ...
  • User Acceptance Testing (UAT) ...
  • Quality Assurance (QA) ...
  • Security Testing. ...
  • Chaos Testing. ...
  • Alpha Testing. ...
  • Beta Testing.
7 Aug 2022

What is cat & UAT? ›

User Acceptance testing also known as Customer Acceptance testing (CAT), if the system is being built or developed by an external supplier. The CAT or UAT are the final confirmation from the client before the system is ready for production. The business customers are the primary owners of these UAT tests.

What is acceptance criteria in PMP? ›

Acceptance criteria represent a specific and defined list of conditions that need to be met before a project can be considered completed and the project deliverables are accepted by the client.

What are the 3 phases of the test? ›

The three-phase test pattern
  • First, you set some stuff up (“Arrange”)
  • Then, you do something (“Act”)
  • Then, you make sure that what you expected to happen, actually happened. (“Assert”)

What are the 3 pillars in Scrum? ›

Understand Scrum

If you carefully scrutinize scrum, you will find again and again the three pillars of empirical process control: transparency, inspection, and adaptation.

What are 3 C's in agile? ›

In this talk we'll introduce DevOps and discuss the three C's of DevOps: Character, Collaboration, and Community.

What is the 80/20 rule in Scrum? ›

The Pareto Principle, commonly referred to as the 80/20 rule, states that 80% of the effect comes from 20% of causes. Or, in terms of work and time management, 20% of your efforts will account for 80% of your results.

What is the difference between UAT and OAT? ›

OAT tests involve verification of procedures, such as performance, stress, volume, support processes, security, backup, and the existence of alerts. Typically, OAT occurs after user acceptance testing (UAT) and is a final verification before a system is released.

What is the 7 step improvement process in ITIL? ›

The Seven-Step Improvement Process

The goal is to define and manage the steps needed to identify, define, gather process, analyze, present and implement improvements. The objective of the seven-step process is to identify opportunities for improving services, process etc and reduce the cost of providing services.

What is the value of acceptance criteria? ›

Acceptance criteria are one of the key ways to keep a development team on track, and to define the scope of a project. They set the limits and the boundaries of a user story, and give teams the ability to confirm when a product works properly, or if a piece of software does what the user needs it to do.

What is DoD and DoR in agile? ›

DoR and DoD are practices that are needed while improving a product. To ensure that the product meets customer expectations, certain features and ideas have to be added to it from time to time, and defining the criteria for the features to be added is absolutely necessary and that's when the DoR and DoD come into play.

What is DoD DoR and acceptance criteria? ›

The Definition of Done (DoD) applies for all user stories that the team is working on. In contrast to this, Acceptance Criteria are defined specifically per User Story as required by the Definition of Ready (DoR). This should clarify how DoR, Acceptance Criteria and DoD relate to each other.

When should acceptance criteria be written? ›

Acceptance criteria (AC) should be written anytime before the user story is deemed ready to enter the Sprint Planning. Usually it is written during the product backlog refinement meeting. AC can be progressively developed and added to a user story during the refinement.

Is Gherkin BDD or TDD? ›

In BDD, to start with, the test cases are first defined on the frontend in a human-friendly language, mostly 'Gherkin'. Once the feature is developed, the test cases are automated in some programming language.

What is difference between Cucumber and Gherkin? ›

Gherkin is a term generally used to refer to a savory pickled cucumber. Gherkins and commercial cucumbers belong to the same species (Cucumis sativus) but are from different cultivar groups.

What is difference between Cucumber and Gherkin testing? ›

Cucumber is an open-source software testing tool that supports BBD. (Behavior-Driven Development). It works with Gherkin because the Gherkin syntax structures plain text so that it can be read by the tool. Cucumber reads Gherkin tests and validates that the code performs as it should.

What are requirements and acceptance criteria? ›

Requirements are what the client / customer have asked for. Acceptance Criteria, often expressed as tests, are used to illustrate Requirements and to indicate, when the tests pass, that the Requirements have been met.

How many types of criteria are there? ›

There are two types of criteria you can use; specific and generic. Specific criteria can be answered with a simple yes, no or maybe.

What are the 2 requirements of an acceptance? ›

Rules of Acceptance

There must be communication of acceptance from the offeree's side. You can withdraw an offer any time before it's accepted. Only the person to whom the offer is made can accept it. You are not bound by an acceptance made by someone else on behalf of the offeree without his authorization.

What is UAT acceptance criteria? ›

If a product meets user acceptance criteria, it means the product is ready for production. UAT activities, in that case, are for completing the system check, its functionality, usability, and bugs. But still the primary goal is to ensure that the product corresponds with the initial requirements and end-user needs.

What is a good acceptance criteria? ›

What makes good Acceptance Criteria? Acceptance criteria define when a work item is complete and working as expected. Express criteria clearly, in simple language the customer would use, without ambiguity regarding the expected outcome.

What are the 4 criterions? ›

Criterion A = Thinking and Knowledge Skills. Criterion B = Organizing skills. Criterion C = Application and Communication skills. Criterion D = Evaluating skills.

How many steps is acceptance? ›

The key steps are denial, anger, depression, bargaining, and acceptance. These are easily memorized.


1. Acceptance Criteria Examples and Explanation
(Everyday Design)
2. User Stories and Acceptance Criteria | How to Write Agile User Stories & Acceptance Criteria
(KnowledgeHut upGrad)
3. How to Write Good User Stories (User Stories and Acceptance Criteria Tutorial)
(The Business Analysis Doctor, LLC)
4. Acceptance Criteria vs Definition of Done (How to write Acceptance Criteria in User Stories)
(JOGO Agile Coaching)
5. AA047 - Acceptance Criteria in User Stories
(Arguing Agile Podcast)
6. User Acceptance Testing (UAT) Types and Best Practices - XenonStack
Top Articles
Latest Posts
Article information

Author: Prof. Nancy Dach

Last Updated: 05/11/2023

Views: 5786

Rating: 4.7 / 5 (57 voted)

Reviews: 80% of readers found this page helpful

Author information

Name: Prof. Nancy Dach

Birthday: 1993-08-23

Address: 569 Waelchi Ports, South Blainebury, LA 11589

Phone: +9958996486049

Job: Sales Manager

Hobby: Web surfing, Scuba diving, Mountaineering, Writing, Sailing, Dance, Blacksmithing

Introduction: My name is Prof. Nancy Dach, I am a lively, joyous, courageous, lovely, tender, charming, open person who loves writing and wants to share my knowledge and understanding with you.