User stories: a beginner’s guide to acceptance criteria

By courtney in Agile on September 22, 2010

Image 0608 full 2x

Last week I described the bones of the user story in the first post of our introductory series on user stories. Briefly, a user story is a description of an objective a person should be able to achieve when using your website/application/software, written in the following format: As an [actor] I want [action] so that [achievement].

For example: As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.

This post adds some flesh to the idea of user stories, in the shape of acceptance criteria.

Where are the details?

At first glance, it can seem like user stories don’t provide enough information to get a team moving from an idea to a product.

Nearly 10 years ago, Ron Jeffries wrote about the Three C’s of the user story:

In a project following an Agile process, user stories are discussed in meetings with the Product Owner (the person who represents the customer for the thing you’re developing, and who writes the user stories) and the development team. The user story is presented, and the conversation starts.

For example: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork.

Questions for the Product Owner might include:

The issues and ideas raised in this Q and A session are captured in the story’s acceptance criteria.


Could our FREE user stories webinar take your User Stories to the next level?

Join our experienced coaches in this FREE hands-on webinar and learn to write great agile user stories & craft an amazing product backlog.

Find out more


Acceptance Criteria

Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.

For the above example, the acceptance criteria could include:

As you can see, the acceptance criteria are written in simple language, just like the user story. When the development team has finished working on the user story they demonstrate the functionality to the Product Owner, showing how each criterion is satisfied.

Including acceptance criteria as part of your user stories has several benefits:

Further reading

So that’s a brief introduction to acceptance criteria and how they fit in with user stories. For more examples of how acceptance criteria work, I really recommend this post by Sandy Mamoli (Sandy is a Wellington Agile coach and scrum master, who we work with on Digital New Zealand).  You might also like to check out this presentation on effective user stories by Mike Cohn.

Want to know more about user stories? Check out our introductory series:

Starting a new project?

Check out our Agile Project Kick-off Kit.