A quick start guide to acceptance criteria for user stories

Acceptance criteria help your team to do the right thing. But if you and your team don’t know what acceptance criteria do, it is difficult for you to start using them in your user stories. 

In this post you will learn an easy way to get your team on board with this practice, by taking notes during the refinement discussions. 

But let's first discuss why acceptance criteria are important. Feel free, though, to skip ahead straight to the note-taking method at the end. 

What are acceptance criteria?

Agile teams use a backlog of work. Items on the backlog may be written in user story format. A user story is a short description of the work, that outlines: 

• Who needs the results of the work
• What the problem is, that is to be solved
• Why it needs to be solved

This “Who & What & Why” is sometimes called the Cohn story format. 

Formatting work items into user stories is simply a thinking tool. Using it is not mandatory. Use it when there is a clear system user problem to be solved. User stories help the team to discuss and share an understanding of the problem that is to be solved.

Why add acceptance criteria to user stories?

One main reason to use user stories is to have a common language between business and developers. User stories describe the need, the problem, in a way that everyone should be able to understand and discuss it.

Using user stories focuses the discussion around understanding the problem. The team can avoid jumping too deeply into technical discussions that could alienate non-technical business stakeholders. With a common understanding of the need, the team can better define what kind of solution would be needed to solve it.

The user story is built from three separate parts:

1. Title
2. Description (the who, what and why)
3. List of acceptance criteria

The title and description define why the problem needs to be solved, and who is going to benefit. 

But the acceptance criteria really define the what of the story.

If you don't use acceptance criteria, you run the risk of: 

• not implementing something that is needed (in which case you may call something Done - only to learn later that it needs to be reworked)
• Implementing something that is not needed
• Not fully sharing the same understanding of what is needed
• Inaccurate effort estimation 

All these risks could cause waste. Your team may need to rework something many times to get it right, or the work may be too large to complete in a sprint. 

Avoid the “What is taking so long?”

Often, the Product Owner is wondering why the development is taking so long. It was supposed to be easy to build the feature. The original effort estimate said one or two weeks of work. Now it has been more than a month. What is going on?

It is too easy for the development team to add too many things, trying to cover all bases. Engineers sometimes like to develop an overkill solution where, upon review, a much simpler approach would have been sufficient. This waste of effort and time could have been prevented by discussing acceptance criteria - it is great for deciding what is not needed.

An example: The devil is in the details

Here is another common problem of not using acceptance criteria: developing features without fully considering all the things that are really needed. Let us look at an example.

Sample user story: changing the password

As a user

I want to change my password

So that I can use the system

This user story describes a problem, that the system should have a way for users to change their password. A solution could be that there is a “change password” option somewhere, and then a view or a popup screen that allows users to change the password. 

Simple, right? Shall we proceed to implement it or estimate the effort of implementing it?

Acceptance criteria reveal the true complexity

Let's discuss a few acceptance criteria candidates. Here are some that could be considered:

• Password is at least 8 characters long
• Password must contain at least one special character
• List of special characters that are checked
• Password must contain at least one small and one capital letter
• Password has to be entered into two separate fields
• Both password fields must match until the registration is possible
• The end user is shown an indicator if the password is not strong enough
• The strength indicator shall change after each edit of the password field
• The reason for not being able to register is told to the user 
• Password has to be at least 8 characters long, 
• The strength of the password is not strong enough: add special characters or numbers
• Please fill all mandatory fields - [field missing information]
• Registration is only possible if the password is strong enough 
• Registration is only possible if all other mandatory fields are filled
• Mandatory fields are clearly marked

Without talking about the acceptance criteria, a simple story like in our example could be implemented, but the logic behind the page would not be ready. The things would surface later, and the team would need to return to the page to make it usable and nice for the user.

Make the effort estimate only after listing the acceptance criteria

By discussing exactly what needs to be done, the team can arrive at a shared understanding. Only after this has been done, you should do the effort estimation. Without acceptance criteria, the page creation could be imagined to take only a few hours or one story point. With all the acceptance criteria, the estimate may change to a couple days or 3-5 story points.

The main benefits of using acceptance criteria

The main benefits of acceptance criteria are:

• A shared understanding of what is needed
• More accurate effort estimates
• More accurate velocity estimates
• Better commitment to the sprint
• Easier identification of too large stories
• Easier splitting of too large stories to smaller ones

How to easily start using acceptance criteria: Document the discussion 

This method is meant for teams that have no previous experience in using acceptance criteria. 

For this process, you need a note-taker or secretary. If you have a Scrum Master, she can be the one.

1. Open the user story so that everyone can see it (very important - you want everyone to instantly see what kind of notes are taken)
2. Start asking questions and providing comments and answers - what does this story mean?
3. The note-taker interprets the questions and comments and writes them down instantly as bullet points under the story description. NOTE: It is important at this point that the note-taker only writes all the comments and questions to the description without waiting for any confirmation or decision. The goal is to document the discussion. Continue this for a few minutes.
4. After a few minutes, or when the discussion is winding down, start to look at the list of bullet points. The items listed are your candidate acceptance criteria. Next stage is to check if anyone disagrees with any of the points listed. If so, focus the discussion on that topic.
5. Finally, explore a few questions:

1. 1. Are all these needed? 
   2. Are there any that seem contradictory? 
   3. Is anything obvious missing?
   4. Do we have too many acceptance criteria? Typically, if you have more than 10, it is an indication that the story could be potentially split to two smaller stories.

First get your team more familiar with acceptance criteria - develop the practice later

You can sum it up very simply - just take notes and document the discussion. Do not worry about formal things like “making acceptance criteria into the form of a question”. All that can come later, if you so choose. 

The added value of documented bullet points and getting the team comfortable with adding them to every story, is more important than following formal rules like that.