What is Acceptance Criteria? Examples, Formats, & Templates

Acceptance criteria are specified parameters or standards that a product must meet to be accepted by both the customer and the end user. Successful development projects need both end users and developers to share a common concept of the desired final result.

One of the most important variables in obtaining success and pleasure, for both the customer and the developers, is a common knowledge of the intended result. When customers request the development of applications as complex as Zoom, it is natural for them to imagine various possibilities regarding the product. Acceptance criteria are designed to prevent ambiguities and ensure that all sides, including the customer themselves, align on a common vision of what the final application should entail.

This blog will describe acceptance criteria, present examples, and go over recommended practices for designing them.

Why are Acceptance Criteria Important in Agile?

In Agile, acceptance criteria are a collection of requirements that must be met for a user story to be marked complete. Acceptance criteria are sometimes known as the "definition of done" since they specify the scope and requirements that developers must meet for the user story to be considered completed. As a product manager or owner, you may be tasked with creating acceptance criteria for the stories in your product backlog. 

Here are some of the reasons that entail the importance of Acceptance criteria:

• Clear Project Scope: They explicitly define what is included in the user story, avoiding scope creep.
• Better Stakeholder Understanding: They assist stakeholders in reaching an agreement on what is expected from the implementation process.
• Strong Foundations for Testing: They act as a reference point for acceptance testing, verifying that the feature fits the specified criteria.
• Coverage for All Scenarios: They define the expected outcomes in various scenarios, which improves program reliability.
• Improved Planning and Estimation: Well-defined acceptance criteria allow for improved sprint planning and workload prediction.

What Makes Good Acceptance Criteria?

Good acceptance criteria give a clear definition of success for a feature or user story. They remove uncertainty, encourage cooperation, and guarantee all the people participating in the project are on the same page. Here are the fundamental qualities of good acceptance criteria.

Simple & Easy to Learn

Acceptance criteria should be short and succinct and easy for developers, testers, product owners, and stakeholders to grasp. Avoid jargon or ambiguous language that might be misinterpreted.

Quantitative and Specific

The description of each criterion should specify a measured result. Rather than stating general criteria, provide quantifiable requirements so that it’s easy to tell if the feature satisfies the intended objectives or not.

Testable and Checkable

A good acceptance benchmark has to be testable. All requirements should be verifiable manually or automatically. There should be an objective measure to verify that the feature functions as planned.

Outcome for the User

Acceptance criteria should be about what the user wants to do and not how the developers should achieve it. Focusing on the value to the user, the development team has freedom while meeting the demands of the customers.

Different Cases

Good acceptance criteria anticipate expected and unforeseen scenarios. Positive situations, error handling, validation rules, and edge cases should be included to make the application more reliable.

Realistic & Feasible

The criteria should match the scope of the user narrative and should be doable within the sprint or development cycle. Break down large or complicated requirements into smaller, more manageable acceptance criteria.

Structural Dependability

Writing user stories in a regular style, such as a checklist or using the Given-When-Then technique, also makes them easier to understand and keeps them consistent. It also facilitates testing and evaluations by using an organized approach.

Aligned to Business Objectives

Acceptance criteria must complement the overall company objectives and product needs. Each criterion should directly add value for users and help to meet project goals.

Stakeholder Feedback

Review and get approval of acceptance criteria with product owners, developers, testers, and other key stakeholders before development. Working together early eliminates gaps, confusion, and rework.

Keeps the Development Going

Clear acceptance criteria serve as a point of reference throughout the development lifecycle. They drive implementation, enable testing, clarify when a user story is done, and ultimately offer better software and more successful projects. 

Who Writes Acceptance Criteria and When?

There are several questions, such as who should write the acceptance criteria. Should you even set acceptance criteria? These questions occur because we are employing user stories. And in user stories, you often state that to give a specific form of value, some specific persona wants or requires something, and then you specify your acceptance criteria.

Take a look at who usually writes acceptance criteria and when: 

Initial Criteria Created by the Product Owner

The Product Owner is usually responsible for determining the acceptance criteria because he/she knows the company’s goals, customer needs, and product vision best of all. This person also defines what result should be delivered and checks if each criterion is relevant and necessary. 

Developer Technological Feasibility Audit

Developers review acceptance criteria to guarantee technological feasibility. They may propose changes, identify implementation issues, or recommend additional issues to be addressed before work begins.

Testers Ensure Feasible Tests 

The QA team ensures that all acceptance criteria are testable. They clarify ambiguous statements, provide measurable conditions, and ensure that the criteria provide a solid foundation for the production of test cases.

Business Analysts Offer Business Clarity

In cooperation with business analysts, they facilitate the improvement of the acceptance criteria because it is their responsibility to formulate them in such a way that it should meet the requirements and needs of the business and can be delivered by developers.

Stakeholders Validate Business Expectations 

Stakeholder validation may help you ensure a feature addresses a business requirement. Feedback avoids misunderstanding and ensures that everyone involved is on the same page before implementation starts. Before you start developing, you need to have well-discussed the acceptance criterion specifics. By defining the requirements before creating any code, the entire team has a crystal clear view of what has to be delivered, and this leads to less rework, fewer modifications, and better sprint planning overall.

Written Before Development Begins

Acceptance criteria are created before a project is developed, but may be revised if the business needs or goals of a project change. Any modification should be communicated to the whole team so as to prevent any misinterpretations in its implementation.

More Effective in Agile Planning Sessions

Acceptance criteria are often defined during backlog refinement meetings, during sprint planning and while talking about user stories in an agile setting. This discussion helps to comprehend the requirements at hand, to identify what should be done and what should not.

How to Write Acceptance Criteria Step by Step?

Acceptance criteria are well-defined to communicate effectively with the team and the stakeholders. It lays forth the expectations on the functionality for developers, testers, and stakeholders. Here are some recommendations for drafting acceptance criteria.

Define Anticipated Results

Acceptance criteria should be defined in simple words what a product or capability should do in terms of the desired result. Each criterion should be specific to avoid any ambiguity about what the development team must provide.

Indicate Each Criterion Independently

Each criterion should be a stand-alone. That implies it should be autonomous. Developers should not have to implement many criteria to satisfy one requirement. Test and review are independent criteria, straightforward to apply.

Use Easy Words

Acceptance criteria should be comprehensible to all stakeholders in the project, including company owners who are not technical.

Define Measurable Results

Never tell somebody how to do something. Concentrate on showing what should happen in certain circumstances. This way you allow developers choice on how to build a feature, as long as the criteria are met.

Ease of Testing Each Criterion

Each criterion must be tested, i.e. must have a clear pass/fail conclusion. If a test cannot establish that a certain requirement is satisfied, then it should be discarded or refined.

Specify the Behaviour of the App Under Certain Situations

Acceptance criteria have to be specific and describe what should happen in the various situations. It should provide validation criteria for the tester and developer to know if the application is behaving as intended in various circumstances.

Set Realistic Acceptance Criteria

Acceptance criteria should be reasonable. Don’t expect the impossible of yourself. Features that are too hard to test need to be simplified, and developers are unable to provide what they can’t build.

Definition of Done Should Be Defined Before Development Starts

Define acceptance criteria before development, ideally during backlog refinement sessions. This gives the developers and the testers a clear idea of the things that they are expected to perform. This also helps to prevent misunderstandings and modifications later on.

Write Acceptance Criteria Collaboratively

Acceptance criteria are often established during backlog refinement meetings, during sprint planning, and while discussing user stories in an agile environment. Discussing them helps to understand the requirements at hand, as well as to define what needs to be done and what should not be done.

What are the Typical Errors While Writing Acceptance Criteria?

Even the greatest agile teams may goof up creating acceptance criteria. Here are some of the most typical acceptance criteria blunders teams make.

Don’t Use Vague Requirements

Vague requirements can make for a lot of confusion, especially if the language is not simple or accurate. Use unambiguous words in acceptance criteria.

Do Not Combine Multiple Expectations Into a Single Criterion

Do not combine more than one expectation in one criterion. If there are many expectations for a feature/functionality, it is best to list them as distinct criteria.

Don’t Ignore Edge Cases

When developing acceptance criteria, it is easy to forget edge situations. But edge cases are significant and should be part of the acceptance criteria. Include any necessary validation rules and situations, including error messages and how the application should respond when it detects unusual requests.

Use Implementation Specific Language

Acceptance criteria should be about describing what the intended result is. Below is the code snippet to show how the functionality is to be implemented. This allows them to determine how best to apply the functionality, without being constrained by implementation-specific criteria.

Don’t Write Acceptance Criteria Too Late

Write acceptance criteria before you start developing. Thus, developers and testers know what they have to accomplish. Don’t create acceptance criteria during development or after development is complete.

Team Review? Don’t Overlook It

It is crucial to go over the acceptance criteria with the team before they are finalized. This ensures everyone is on the same page and helps to minimize misunderstandings. 

What are the Acceptance Criteria Examples?

Reading about acceptance criteria examples is beneficial. Seeing them used in real-world settings is what makes them stay. The examples below include the most frequent team structures and kinds utilized in practice, as well as a direct comparison of effective and ineffective criteria.

Simple Checklist Example: Login Feature

A checklist scenario type would be the best choice for describing the login process because there are several independent and integral requirements which can be easily verified upon completion.

• A registered user who provides their valid email address and a correct password is redirected to the dashboard
• A registered user who provides an invalid password is prompted regarding wrong credentials and redirected to the login screen
• An invalid password entered three times consecutively locks the account for 15 minutes
• The login page loads in under 2 seconds on a stable broadband connection
• The password field is masked when typing
• A registered user who clicks on the remember option is automatically logged in for 30 days.

Example of Given-When-Then Flow: Password Reset

The Given-When-Then format suits the password reset procedure best because the outcomes depend mainly on the given conditions and the actions taken.

• Given there is a registered user, when the user goes to the password reset page and fills in their valid email address and clicks Send Reset Link, then an email containing a reset link is sent to the user within 60 seconds, after which a success message is displayed on the screen.
• Given there is a registered user, when the user clicks on a password reset link generated more than 24 hours ago, then a warning message showing the reset link expiration is displayed alongside an option to resend a reset link.
• Given there is a registered user, when the user utilizes a valid password reset link to set a new password that meets the complexity requirements, then the set new password is saved, the reset link is expired, and the user is redirected to the login screen.

Functional Example: File Upload Function

The functional acceptability criteria for a file upload feature are based on what the system must perform in response to various user actions and input situations.

• The system supports file uploads in PDF, PNG, JPG, and DOCX formats.
• Files larger than 10 MB are refused, and the user receives a particular size-limit error message.
• Within 5 seconds after uploading a file, it appears in the user's document library.
• Every submitted document receives a unique file ID, which is stored in the user's account.
• A user may upload up to five files at once without affecting upload speed.

Non-Functional Example: Dashboard Performance

Non-functional acceptance criteria for a data dashboard focus on how well the system functions rather than what it presents.

• The dashboard loads entirely in 1.5 seconds for customers with a normal internet connection.
• Despite having 1,000 concurrent user sessions, the dashboard remains completely functional and responsive.
• All data on the dashboard is refreshed within 10 seconds of an underlying data update.
• The dashboard's interactive parts all fulfil WCAG 2.1 AA accessibility criteria.
• The dashboard module has 99.9% uptime over any rolling 30-day period. 

What are the Acceptance Criteria Formats and Templates? 

There are no hard and fast guidelines for creating acceptance criteria. The ideal approach is easily understandable by the complete team, which makes testing an easier procedure. The Acceptance Criteria Format adopted should be immediately visible adjacent to the user narrative, accessible, easily tested, and consistent in the statement of requirements.

The most recommended method among agile teams to define acceptance criteria is a Verification Checklist or Given/When/Then. There are several differences between the two forms of organization that might help you decide which of the two is best for a given scenario or team.

Given/When/Then

Acceptance criteria may be written in several formats, but the best format is the Given/When/Then format. It clearly defines what requirements need to be satisfied in a given scenario provided by the User Story.

This kind of acceptance criteria is mostly utilized when the feature is anticipated to have some user involvement or when numerous scenarios are required to adequately explain the modifications needed to accomplish a user narrative.

The Given/When/Then structure helps developers to describe the behaviour of an implemented capability succinctly and gives a handy scenario for testers to examine. This is a very easy style to comprehend for anyone not directly engaged in testing and may be used to illustrate numerous examples and scenarios where a feature might behave differently.

Format of Verification List

Some development teams choose to specify acceptance criteria as a series of statements a product should meet, rather than a more straightforward way.

The collection of assertions may be readily translated into a series of tests to verify the built feature satisfies all the criteria stated in the user narrative.

This method works well when the specific feature has simple needs that can be readily broken down into well-defined statements.

The verification checklist provides a handy reference for developers and testers to use for testing. It provides a simple chance to verify that each criterion is implemented appropriately. Testers should be able to cross off each assertion after they have finished checking/verifying the related requirement.

Which Approach is Better?

Regarding the acceptance criteria template or format, there is no better technique. Both approaches have advantages and disadvantages and can be chosen depending on the type of changes being performed. Given / When / Then is good for describing scenarios and many situations. 

The verification checklist is simpler to utilize for a collection of simple criteria clearly expressed in a statement.

Anyway, the important reason for selecting one of the two structures is to ensure the acceptance criteria are well described in an easy-to-understand and testable way. Both techniques facilitate communication between the team members, assist the testers in generating the test cases, and make sure that the requirements are implemented properly and enough. 

How are Acceptance Criteria Different from User Stories?

User stories and acceptance criteria are two closely related but separate concepts. Both acceptance criteria and user stories are crucial in agile project management because one cannot be without the other. The first one is about describing the characteristics and requirements the product should meet. And the second one is about the aims and objectives the product should reach. They together determine the scope of labour, the intended result and the conditions of development.

User Stories Describe What the User Wants

User Story: This is a description of a certain function from the user's point of view. It is a textual description. It specifies who requires the function, what is needed, and why it is to be requested. This is the classic way to write a user story:

As a user kind, I desire some feature so that some reason/description of objective.

An example of a user narrative is:

As a consumer, I want to store my shipping address so that I may check out quickly next time.

A user narrative describes a feature at a high level, but does not explain expectations. This is intended to support conversation and cooperation amongst the stakeholders in the project.

Acceptance Criteria Determines When Work is Done

Acceptance criteria, in turn, establish the requirements that are needed to finish or deploy a narrative. They provide additional information that extends the user narrative. Below are the acceptance criteria for the above user narrative:

• Customers may store multiple delivery addresses
• Setting the default address during checkout
• The customer may edit or remove their address
• If you leave a required address box blank, an error message will be shown

These clarifications make the acceptance criteria clear enough for developers to estimate effort and execute the product appropriately. Besides, they supply the testers with the particular criteria to be utilized to assess the solution deployed.

So, the key distinction between user stories and acceptance criteria is that user stories describe the goal, while acceptance criteria specify the conditions for meeting the goal. Another way of saying it is that the user narrative informs us of the objective and the acceptance criteria indicate that the goal has been accomplished. Consider the user narrative to be the goal and the acceptance criteria the journey. The two concepts are complementary and go together.

What is the Purpose of User Stories and Acceptance Criteria?

User stories and acceptance criteria are not interchangeable. They have distinct uses and should not be used interchangeably. User stories and acceptance criteria go hand in hand. If the user narrative is unclear, too broad, or doesn’t include enough specifics, developers could construct the incorrect functionality, which is a waste of time, money and resources. At the same time, if the plot is too detailed, there will be nothing left for developers to interpret. 

Likewise, if there are no acceptance criteria, developers and testers will have nothing to depend on when evaluating the job that is done. Hence, it is important to plan user stories and acceptance criteria well. What most businesses using agile do is to generate user stories first and establish acceptance criteria with the stakeholders before developers start working on the assignment.

How is Acceptance Criteria Different from the Definition of Done?

To understand the difference between Acceptance Criteria and the Definition of Done, let’s first examine what the Definition of Done is. 

It is a criterion that should be used for each item in the project, no matter what kind of narrative it is. It specifies generic product criteria that have to be met before a product is deemed complete or ready to be deployed.

Thus, DoD addresses the question “what does it mean for anything we produce as a team to be done? It sets a common objective, a bar that each product increment should clear.

The Main Difference

Scope is the gap between acceptance criteria and definition of done. The first is individual user tales, the second is the product as a whole. Acceptance criteria are narrative and particular; DoD is project-specific. Thus, AC asks ‘what should this tale be able to do?’ but DoD asks ‘what level of quality should this and every other feature meet?’

On Installation

Acceptance criteria are usually defined in the conversation about the backlog. They need to be detailed so the team knows what to do and what not to do. However, in most situations the DoD is negotiated once, at the team or product level. Usually set at planning meetings at the start of each project or product increment and tracked throughout to completion.

A Mistake We All Make

Often project teams mix acceptance criteria with definition of done. In instances, many individuals like to add process-related criteria to user stories (“code should be peer-reviewed”, “automated tests should pass”). In fact, any such process-related standard should be part of DoD, not individual tales, as it should apply to all stories in the product.

Why Not to Use One Instead of the Other

Do not use definition of done as a replacement for acceptance criteria and vice versa. The two notions are complementary and should be utilized together. For example, a user narrative may have defined acceptance criteria, but if it does not fulfil process-related requirements, then it is not done. Put another way, if you don’t fulfil more broad criteria set by the DoD, you can’t release a product increment just because it satisfies all user story requirements. 

How are Acceptance Criteria Used in Scrum and SAFe?

Acceptance criteria are an important feature of Scrum and the Scaled Agile Framework (SAFe). Their main aim is to verify that the produced features satisfy the requirements. But with SAFe, criteria are not just created for user stories, but also for large-scale projects. Therefore, professionals should know the difference in the use of Scrum and SAFe. 

In Scrum, acceptance criteria assist developers in identifying what requirements will be satisfied in a Sprint. They also assist testers in constructing checklists to examine the completeness of implementation. Also in SAFe, criteria are used to allow teams working on separate Agile Release Trains (ARTs) to communicate. 

Using acceptance criteria helps eliminate mistakes caused by misunderstanding of duties and deliver maximum value. 

What are the Common Mistakes When Writing Acceptance Criteria?

1. They are too wide.

Having acceptance criteria that are too broad negates the purpose of having them. Yes, it should not include test cases, but it should specify what has to be done to fulfil the user narrative.

2. Does not consider user experience.

Nowadays, a decent product is a must-have. And this doesn't simply mean piling feature after feature; it also involves creating goods and features that provide positive experiences at every stage.

This makes user experience even more important than previously.

If your Acceptance criteria do not take into account the end-user experience, you risk failing to meet your consumers' genuine demands.

3. Write on the "how" rather than the "what".

Acceptance criteria should be clear and succinct, but not so exact that they begin to drive execution.

Remember that the acceptance criteria should be a collection of requirements that must be completed to determine if a user narrative is complete or not. If the product owner specifies "how" the user narrative should be implemented, this may be seen as micromanagement. By specifying the "what," developers may be creative and create novel solutions to the challenge at hand.

4. Write acceptance criteria as you construct.

While the product owner is often responsible for developing acceptance criteria, any member of the cross-functional team might do so. In certain circumstances, I've seen developers write acceptance criteria as they're constructing the product. While it may assist the developers in defining what they need to achieve, it may also mislead the other team members by providing inaccurate information about the user narrative. The team must define acceptance criteria before beginning development of a specific story or feature so that everyone has a clear knowledge of what they need to complete before the sprint planning meeting.

5. Having preconceptions.

It might be paradoxical to create acceptance criteria that seem too simple. While something may seem apparent to the product owner, it may not be so for the developers. Remember that developing a product is a team sport; thus, everyone should be encouraged to give their fair share. This involves writing acceptance criteria. Even if something appears apparent, setting it down helps the development team have a common understanding of the work that has to be done. This, in turn, lowers waste in the development process. 

What are the Best Practices for Acceptance Criteria?  

Focus on the End-User: Acceptance Criteria should be based on the user's requirements and expectations. Consider, "What problem will this feature solve for the user?" as well as "How will the user interact with this feature?" What are their specific goals?

Define Clear Outcomes: Acceptance Criteria should be detailed and quantifiable so that everyone understands the desired result. When feasible, employ objective measurements (metrics) to show that a user narrative has been effectively accomplished. An excellent example is: "This page should load in X seconds."

Consider Alternative Variants: Think beyond the obvious and incorporate other versions of the user narrative or situations in which the user might engage with the feature differently.

State It Simply: Avoid using too convoluted terminology, jargon, or methods that will only annoy the Development team.

Frequently Asked Questions

Do acceptance criteria only apply to user stories?

Work items may be of several sorts, including user stories, features, requirements, tasks, etc. Acceptance criteria are not only for user stories. Teams may apply acceptance criteria to any work item type that describes a product or a requirement.

How do acceptance criteria contribute to the Definition of Done in Agile? 

Definition of Done is a quality metric that indicates for teams when a work is done. Acceptance criteria different from DoD. Acceptance criteria make sure that everyone is aligned on what requirements a user story or feature has to fulfil before being implemented. DoD makes sure that the developed solution fulfils quality requirements.

Can acceptance criteria be used as a form of documentation in Agile projects? 

Acceptance criteria may act as documentation, since they describe the needs of a feature. But if you need more precise knowledge to develop software features, it is best to rely on documentation.

Can we modify acceptance criteria after we start working on a sprint?

If the requirements change, the team should evaluate how these changes may impact the current iteration. If it's not a big request, then the team may pick it up during refining. It’s not a good idea to make big modifications to the sprint backlog, since it will interrupt the flow of work amongst the team members. Only the product owner may reject modifications to the backlog.

Who owns acceptance criteria?

The product owner owns the acceptance criteria, since the product or project owner determines the requirements a feature must meet. Still, other stakeholders may propose adjustments before the criteria are adopted.

Do you have any acceptance criteria for technical spikes?

There are no criteria when a team begins working on technical spikes. But the team should have explicit acceptance criteria as to what the spike is expected to offer. The spike might have consequences that are comparable to acceptance criteria.

If acceptance criteria are not clear, what should one do?

Developers should not build on requirements with ambiguous acceptance criteria. The team should work with the product owner and stakeholders to develop more granular requirements. Also, if various people on the team read the same phrase differently, you may need to better define the criterion.

What is the relation between acceptance criteria and testing?

Acceptance criteria are the foundation of testing. Developers and testers evaluate them, and they may construct a collection of appropriate tests and test cases. So acceptance criteria guide teams in creating automated tests.

What tools may be used to develop acceptance criteria?

Most agile systems allow teams to specify acceptance criteria when creating user stories or backlog items. Some of the prominent tools that help in developing criteria include Jira, Azure DevOps, Rally, etc. The preferred tools will depend on the workflow and toolchain of the team.

How do acceptance criteria enhance the quality of the software?

The acceptance criteria improve the quality of the software as they assist testers and developers to consider all conceivable instances, including edge circumstances, before the implementation of a feature. Moreover, they also assist in preventing scope creep, since they ensure the team and stakeholders are aligned on the requirements. This means developers design software solutions that provide greater value to end customers.

How many acceptance criteria should I write for a user story?

No typical response to this question. A user narrative should include sufficient criteria to guarantee the product being developed satisfies the needed quality and scope. Also, if there's an overabundance of criteria in a user narrative, it should be divided down into smaller tales.

How are acceptance criteria different from test cases?

Test cases are the real procedures that need to be followed to test if the developed functionality is meeting the requirements. The acceptance criteria, in contrast, specify what should be supplied as part of the product and the requirements this feature should meet.

What are the examples of good acceptance criteria?

Let's imagine we want to build a password reset mechanism. Below are some of the possible requirements for this feature:

• Users may reset their password by entering their email address.
• Users may request a password reset link via email.
• This link is accessible for a short amount of time.
• Users may create a new password using a unique URL.
• User creates new password. Message to confirm new password.

What are the two kinds of acceptance criteria?

There are two basic kinds of acceptance criteria: scenario-based criteria and rule-based criteria. Scenario-based criteria specify a scenario which should be achievable in the application under test, in a Given/When/Then format. But the rule-based requirements are just assertions which the application has to satisfy.

What is an acceptance checklist? 

An acceptance checklist is a list that assists developers, testers and product owners to monitor the criteria that need to be met before a user story or feature can be approved. Review this checklist to make sure all applicable items have been checked. 

Conclusion

Acceptance criteria help the Agile teams know what to do to successfully deliver a given feature and to get it to perform correctly. The criteria should be clear, explicit, easy to test, and practical so as to minimize misunderstanding and to keep the emphasis on the result and user-oriented functionality. You can write it as a checklist or in the Given/When/Then format. It also has to be matched with the user stories to understand what has to be done throughout the development phase.

In general, acceptance criteria should be used to simplify the work of teams, to ensure the delivery of the desired product, to remove superfluous features, and to control development processes to satisfy the users’ expectations.