A (boring) reference for Acceptance Criteria

I’m often asked for a good reference that explains the concept of ‘Acceptance Criteria’. Whilst there are some good resources, generally I find them written in a way which isn’t that easy to grasp.

Acceptance Criteria are often referred to by different names, such as ‘Rules’ or ‘Conditions of Satisfaction’. The name really doesn’t matter, so long as the people working together know that they’re referring to the same thing. Since they’re most commonly referred to as Acceptance Criteria, or ‘ACs’ for short, I’ll just continue to call them that.

ACs form part of a product backlog item, detailing requirements which must be satisfied in order to call an item ‘done’. This means that they’re an important tool for the Product Owner to express constraints, and they’re a reference for the other members of the team to guide what to build and how to build it.

Here’s an example of a product backlog item with some ACs:

As a user with contacts saved in my phonebook, I would like to be able to sort my contacts, so that I can more easily find the contact that I’m looking for.

Acceptance Criteria:

  • The user can sort contacts by surname.
  • The user can sort contacts by first name.

As you can see, the first part of the backlog item describes what the user of the product wants and why, so as to inspire conversation and keep focus towards the user outcome, and then the acceptance criteria stipulate some requirements that need to be satisfied during development.

Below are 8 guidelines which I think can help with shaping well written ACs.

  1. Make them independent:

If you keep each AC independent from one another as much as possible, that can help with splitting them in order to defer some of them until another time (or never), which allows you to maximise the value of what you deliver.

So instead of:

  • The user can sort contacts by either surname or first name.

Try and split this to two points — 1 for surname and 1 for first name, like in my above example. Maybe you can just deliver surname first and then find out if users really need to sort by first name.

2. Make them testable:

If you write each AC to be verifiable as either true or false, that helps with removing ambiguity about what constitutes ‘done’.

Instead of:

  • It’s clear when there’s a problem with the internet connection.


  • An alert is shown when the internet connection fails.

What’s clear to one person might not be clear to another, but with the second example it’s concrete that an alert must be displayed.

3. Phrase them as questions:

Again to help with making them testable and less ambiguous, it can be helpful to write ACs as questions.

For example, try something like this:

  • Can the user sort contacts by surname?

This can only result in a true or false result.

4. Write them abstract of a solution:

Generally, it’s a good idea to write ACs abstract of a solution. In my experience this becomes more challenging as product backlog items become more granular.

Here’s an example of some ACs which prescribe a solution:

  • The user can sort contacts by surname when they tap on the sort icon in the menu.
  • On first tap it sorts A-Z, and on second tap it sorts Z-A.

Keeping the design solution out of the ACs has a number of benefits. Mainly however it empowers the delivery team with freedom to explore and try out different options. They might find a better design, or one which is just as good but half the cost to develop.

There are times however when there’s a need to prescribe a solution. For example if there are regulatory requirements that must be followed in order for a company to comply with the law, then it makes sense to prescribe those business rules in the ACs as they’re genuinely non-flexible.

In a nutshell, I think it’s a good idea to try and prescribe only as much as is truly required.

5. Include non-functional requirements:

The ACs can also be a place to specify any non-functional requirements. I like to think of non-functional requirements as things relating to ‘how’ something operates or is developed, as opposed to the ‘what’.

Here’s an example of some non-functional requirements:

  • The response time should be less than 300ms.
  • The service should be HTTPS encrypted.

You can see that this isn’t specifying what to build, but how it should perform and conform.

6. Use an appropriate level of detail:

You can write ACs at varying levels of detail.

For example:

  • When the contacts are sorted, the first surname should begin with A.
  • When contacts are sorted, after surnames beginning with A should come surnames beginning with B.
  • When contacts are sorted, after surnames beginning with B should come surnames beginning with C.
  • Etc…

This is a pretty extreme example, but you get the idea.

The main purpose of writing things down in the first place is to act as a placeholder for conversation, so with that in mind, try to write only as much as is required for everyone to be able to develop the same understanding. There are other tools for confirming understanding, like Example Mapping.

7. Using Given / When / Then:

Sometimes you might see ACs written in a different format, like this:

  • Given I don’t have any bananas in stock, when I try to sell a banana, then I shouldn’t be able to sell a banana.

This really is no different to writing an AC like this:

  • The user is unable to sell bananas when none are in stock.

Both say exactly the same thing, but structured differently.

The ‘given — when — then’ format comes from Behaviour Driven Development (if you want to learn more about that, then visit Cucumber.io). My preference is not to write ACs in this format as it makes them overly verbose.

8. Utilise the Definition of Done

You can think of the Definition of Done (DoD) as ‘global ACs’, i.e. they need to be satisfied for completion of every product backlog item (or the vast majority of them).

Here’s an example of an AC that is likely to go in the DoD:

  • Product help guide updated.

By putting it in the DoD it removes the repetition of writing it in each backlog item. Plus if the DoD gets updated, then you only need to update it in the main reference.

Lastly, I just want to say that what’s written is important, but the conversations about what’s written are even more important. Well written ACs have little value if the quality of conversation doesn’t match.

If you have any feedback or suggestions for how to improve this post, then please get in touch.