What are acceptance criteria? Examples, Types & Templates

Define acceptance criteria or validation criteria in testing – what are they, and how do you go about creating them? In this article, we’ll look at the guidelines for acceptance criteria, how they relate to user stories, sharing acceptance criteria examples and templates, and best practices.

When you’re developing software and mobile apps, it’s important to make sure you define your expectations as early as possible in the process.

If you don’t, you run the risk of creating a piece of software that is poorly made and that your target audience just doesn’t want to use.

And if your target audience isn’t interested in your product, your startup isn’t likely to last very long.

One of the ways you can define expectations is through the use of entry requirements.

Not sure of the benefits of entry requirements in testing? Don’t worry. In this guide, we’ll show you what acceptance criteria are and how you can use them when creating your software.

Let’s start with a definition of what entry requirements are and how they are used.

Acceptance criteria: definition

Define acceptance criteria are the conditions that a piece of software must meet to be accepted by a user. The concept of entry requirements is a critical part of the Agile methodology.

By ‘user,’ we mean a customer or system – it depends on the type of product you are creating.

Now at this point, you might be thinking: ‘I thought you were all about the lean startup methodology rather than Agile at You are launched?’ And you would be right; we believe that the lean startup has many more advantages than Agile when it comes to the complex needs startup have.

However, entry requirements can help startups get to market sooner and ensure that developers focus on what customers want to see. This means we think that the concept of entry requirements makes an excellent addition to the lean methodology!

Validation Criteria are used alongside user stories. You create a user story and then determine the entry requirements that will mark your user story as complete when validated and signed off. We’ll go into a little more detail about how entry requirements and user stories work together later on.

The good news is that entry requirements are very flexible, and you can use them to fit your business needs and product requirements. There are a few criteria you need to bear in mind though. 

Acceptance criteria need to be:

1. Simple and to the point so as many people as possible can understand them;
2. Binary – they need to be pass/fail;
3. Can be measured in some shape or form;
4. Are open to interpretation – meaning there are several ways they can be completed;
5. Technology agnostic – they need to work regardless of the browser or phone the user has;
6. Focused on the end result – not the approach. Validation Criteria need to be focused on your customers and their goals.

Who is responsible for creating the acceptance criteria?

Anyone can define the acceptance criteria for a piece of software. However, we recommend that it is done by someone who is not involved in the development process, like a product manager or possibly even yourself. This means the entry requirements are independent and not influenced by what the development team wants the product to do.

Whoever is responsible for the entry requirements, the criteria need to be well-communicated and simple to understand. We’ll go into a bit more detail about how to create solid criteria later in this article.

The benefits of using acceptance criteria for your startup

The critical advantage of Validation Criteria is they help identify what your user wants rather than what you think they want. This can be the crucial difference between your product succeeding and your product failing.

The secondary advantage is that entry requirements ensure that everyone on the project knows what needs to be done. Given that one-third of projects fail because of poor communication, it’s incredibly important to ensure the whole team is going in the same direction.

Acceptance criteria will help you and your development team:

• Understand what conditions need to be met and how they will be met
• Identify risks and put measures in place to mitigate against them
• Ensure everyone is on the same wavelength – from developers to product managers. Think about it this way… if you hired a developer with no prior knowledge of your business or software, they should still be to understand and work on your software
• Avoid scope creep – you can focus on the criteria defined at the start of the project and easily say no to anything that doesn’t add value

Acceptance criteria and MVPs – how do they work together?

If you’re looking to create a minimum viable product (MVP) to help you get to market sooner, entry requirements are a must.

Acceptance criteria mean you can focus on the features that your target audience wants to see, meaning you can cut out the fluff. Plus, as entry requirements are great for reducing scope creep, you can launch quickly ahead of your competitors.

Find out more about using an MVP in software development.

Acceptance criteria examples

You can use acceptance criteria examples to help you understand the features and functions of your product or service. This helps you determine whether the product or service will meet the needs of your customers. It also helps you identify any gaps between your current offering and what your customers need.

Now you know a bit more about entry requirements – how do you use them to help develop your software?

The first step: creating a user story

The first part of the Validation Criteria process is to write a user story. A user story is a short sentence that focuses on the user, the feature they want to see, and what they ultimately want to achieve. 

User stories typically follow the following structure:

As a [user type], I want [a feature] so I can [achieve a goal/satisfy a need]

So, for example:

As a shopper, I search for a list of products so I can choose the one I want to buy

How many user stories do you need to have in place? You’ll be likely to need multiple user stories for each product, depending on the functionality. We’ve found that five to ten are typically enough but don’t panic if you have more or less.

Try creating a user story for your software or product now – keep it simple and relevant to what your customers want to see.

The second step: defining your acceptance criteria requirements

When you have your user story in place, you can create your acceptance criteria just like in our sample. Validation Criteria are typically either:

• Scenario-based – how to complete a particular action
• Rules-based – what parameters a user will come up against

The good news is that there are no right or wrong ways to create entry requirements – as long as the criteria work for your team, and everyone is in agreeance. 

Some startups write their entry requirements down as a checklist, while others use a Given/When/Then (GWT) sequence. Again, go with the option that works best for your team. As a rule of thumb, checklists are easier to put together, but a GWT framework will give you more specific criteria.

Taking the user story described in the first step, your entry requirements using a checklist could be:

• Users can access the website;
• The user can search for a specific product;
• Users can click on a thumbnail image for more information.

Using the GWT framework, it could be:

• Given that I’m on the website
• When I search for the product I want to buy
• Then I can find all the products that fit my requirements

Your developers can then work through the list, validating the individual points and signing off the user story when all the Validation Criteria are complete.

Congratulations, you’re one step closer to creating a piece of software that your target audience will love!

If you’d like to know more about Validation Criteria, this article has some really useful examples.

Acceptance criteria templates

If you’re still not sure about how to write Validation Criteria, the good news is there are plenty of templates available online, both free and paid for. 

Just download and adapt to your specific needs.

• Validation Criteria template on the Aha! website;
• Entry requirements template on the Clarity website;
• Quality Standards template on the Powerslides website.

Guidelines for writing acceptance criteria

Writing Validation Criteria for the first time can seem daunting, but once you get the hang of it, you’ll be using them on all of your projects. 

Here are some of our top tips for making the most of entry requirements in your software development process.

1. Start early (but not too early)

You need to have your acceptance criteria in place before you start developing your software. That way, all your developers will know what they need to look out for.

However, you need to have a good handle on your product before you put your entry requirements together. If you don’t, you could potentially put Quality Standards into place that are too hard to achieve or that suddenly become irrelevant.

2.  Don’t make your criteria too broad or too narrow

Overly specific acceptance criteria may be harder to sign off on, while overly broad Validation Criteria can be too vague. It’s important to get the balance right.

If you have more than five entry requirements per user story, look at splitting the story into two. It’s generally better to have more concise user stories than a handful of unwieldy ones.

3. Keep your acceptance criteria simple and jargon-free

It’s important to make sure everyone can understand the acceptance criteria in place, from project managers to investors. This is why it’s best for someone detached from the development team to work on the Validation Criteria.

Clear and to-the-point, criteria will make it easier for everyone to be in agreement and understand what is going on. It will also ensure there are no incorrect assumptions made.

Using active voice rather than passive voice can really make a difference, as well as focusing on the positive rather than the negative.

4. Use the INVEST model

The INVEST model (created by Bill Wake) can help you write better user stories and entry requirements. 

As part of the INVEST model, you need to ensure your criteria are:

• Independent. They aren’t dependent on other acceptance criteria and user stories;
• Negotiable. The user story isn’t so prescriptive that there is only one solution;
• Valuable. The criteria will provide genuine value to your customers;
• Estimable. Your developers can understand and implement the user story;
• Small. The criteria are small, easy to check, and will offer fast feedback;
• Testable. You can quickly determine if the criteria have been completed.

In summary: the power of acceptance criteria in testing

The second most significant reason why startups fail is that there is no market need for the product that has been created. This means you need to do all you can to ensure your idea works as it should for your target audience and that there is no ambiguity just as we’ve mentioned in our Acceptance Criteria examples above.

When you’re creating software or a mobile app, entry requirements can give you the confidence you need to move forward with your plans.

Remember, there are no hard and fast rules for how to create entry requirements. If they lead to a successful launch and mean your customers are happy with the product you’ve created, you know you’ve done a good job.

You might also add Acceptance Criteria Requirements as a section in your Startup Requirement Document.

Frequently Asked Questions (FAQ)

Need help with your Validation Criteria requirements? You are launched can get you up and running

We specialize in-app and software development and have been working with startups, venture companies, and accelerators since 2014. 

We’ve learned a lot about the development process over the years, and we want to share what we know to help your business thrive.

Contact us today to see how we can help you develop, refine, and launch your startup idea for the best chance of success.