User Story Acceptance Criteria

To be able to work on a story, the team members need to understand what is the expected outcome. The expected outcome varies for each story and the product owner needs to make sure that everybody knows what it is in each case. This is where the acceptance criteria steps in. It is a tool for verbalising what distinguishes a done story from work in progress.

Optimally the acceptance criteria is defined exclusively by the customer, but they may require help from the product owner or even the team in identifying and formulating a practical criteria. If the criteria comes solely from the team, it may lack objectivity and user perspective.

Acceptance is not the only stage which needs a criteria. In addition to user story acceptance criteria, there are also criteria which is consistent with all stories the team delivers. This criteria is decided by the team and recorded in the Definition of Done (DoD). At the end of each sprint, stories are subjected to both the Acceptance Criteria and the DoD and only the deliverables which meet all criteria can be released to the customer. The remaining stories return to the backlog and generally are prime candidates for the next sprint.

Should I write a user story acceptance criteria? What if I don't? There are quite a lot of professionals who don't use a written acceptance criteria. In some cases it's not a big problem, since some features are quite intuitive. Testing engineers are often able to deduct and use their intuition to form the criteria in their heads. Make no mistake, where there is testing, there is an acceptance criteria. It's just made up by one or more testing engineers with or without consulting a developer, the product owner or someone else. You cannot avoid having an acceptance criteria. But you are free to decide if you want to contribute to it.

Imagine you're going somewhere. How do you know you've arrived to your destination? Let's say the destination is a restaurant. When your navigation app takes you near the address, you start looking for the sign that says the name of the restaurant. If there is no sign to be found, you might go in and ask if they know where the restaurant is. You might check the address from one or more alternative sources.

A number of things can go wrong in the above example, and that's what the testing engineer would be figuring out if this were a product test case. But the example shows you a criteria which is easily understood in the same way by anyone who reads it. You could verbalise the above criteria like this:

We can see from the criteria that there are quite a few options available in an acceptance criteria. Do we want the sign to be anywhere on the building, above the door, near it (how near?), just visible enough (how to estimate this?), etc. Is the sign visible if it's dark outside or if the sign is not lit? These are the kind of details the testing engineer may need to be able to cover all the cases.

We need absolute, binary (yes/no) acceptance criteria which is easy to test against. The story either passes the criteria or it doesn't. All team members should be able to evaluate the story exactly the same way against its acceptance criteria without interaction with other team members. If it becomes obvious that the criteria has a flaw, it can be discussed and iterated further. But the necessity is that the criteria needs to show us if the story is done or not.

It's good to have an acceptance criteria when developers start designing the implementation. Having an acceptance criteria makes it easier to explain what the story is about. It's also a good tool for questioning the requirement. When you get the team involved, you're going to get great input and ideas both on the implementation but also the requirement itself. You should embrace any feedback.

The acceptance criteria should not be considered sacred. If it has room for improvement, it can improve through input from the team. If the acceptance criteria was "given from above" and you can't touch it, the customer may or may not end up happy. Often test engineers provide the best comments and ideas for the criteria.

It is true that stories should not be altered during the sprint, but if the team considers an acceptance criteria to be lacking in some way, it should be improved, even in the middle of a sprint.

Many of the examples are about unit testing, but the concept of an acceptance criteria works on many levels. You can use it for business requirements as well as epics and other items you use to describe a goal.

For a higher level business requirement, also the acceptance criteria needs to be on a higher level.

For example:

This acceptance criteria doesn't say anything about buttons, accessibility, interfaces or any other technical detail, since its content is more of a strategic importance. But it implies questions like "which social media accounts need to be supported?" and "does the user still need an account in our application or is the authentication enough?". This is an example of a good business requirement, which leaves room for the product owner to do some research and document the need on the story level.

One of the formal ways of writing acceptance criteria is the given-when-then -notation. It consist of 1) a starting state, 2) an event or action, and 3) the result.

Here are some further examples of the given-when-then -notation:

This notation is also used by some testing tools such as Selenium. The given-when-then -notation, just like any proper acceptance criteria, serves both the implementation and the testing of a story.