How to wrtie Acceptance Criteria for user story in agile projects

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

An 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.

  • Card – stories are traditionally written on notecards, and these cards can be annotated with extra details
  • Conversation – details behind the story come out through conversations with the Product Owner
  • Confirmation – acceptance tests confirm the story is finished and working as intended.

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:

  • What information needs to be collected to allow a user to register?
  • Where does this information need to be collected/delivered?
  • Can the user pay online as part of the registration process?
  • Does the user need to be sent an acknowledgment?

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

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:

  1. A user cannot submit a form without completing all the mandatory fields
  2. Information from the form is stored in the registrations database
  3. Protection against spam is working
  4. Payment can be made via credit card
  5. An acknowledgment email is sent to the user after submitting the form.

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:

  • they get the team to think through how a feature or piece of functionality will work from the user’s perspective
  • they remove ambiguity from requirements
  • they form the tests that will confirm that a feature or piece of functionality is working and complete.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s