Boost Agile » Blog » User stories part 2 – Acceptance criteria

Boost agile blog

User stories part 2 – Acceptance criteria

Posted by on 26 Jun, 2012

In the first post in our series on user stories, we defined user stories. We also discussed their benefits and how they are used in an Agile project. Today we’re explaining acceptance criteria.

As we know, user stories follow the format: As an actor I want action so that achievement. How can such a simple statement provide enough information for a team to build a product? The answer is acceptance criteria.

What are acceptance criteria?

Acceptance criteria define the paramets of a user story and determine when a story is completed and working as expected. They add certainty to what the team is building.

Here’s an example of a user story:

As a user of the library catalogue, I want advanced search options on the front page so that I can quickly and easily refine my search.

The acceptance criteria are written in simple language that the customer would use, just like the user story. For the example above, the acceptance criteria could include:

  • I can limit the search by format/type.
  • I can delineate the search by date range.
  • I can limit the search to publisher information such as title, author, subject, place, publisher and call number.
  • I can restrict the search to a particular website/catalogue, collection.
  • I can find advanced search options – advanced search options are carried through as filters to search results page.
  • I can filter by availability.

When are they written?

The Product Owner (the person on your team who represents the customer” } may write the acceptance criteria at the same time as they write the user stories, especially if the acceptance criteria will help the team with estimation.

They may also write the acceptance criteria when the story is picked.

Acceptance criteria will often emerge out of multiple conversations between the Product Owner and the development team when they start discussing the user story. The issues and ideas raised during these conversations can be captured in the acceptance criteria.

The only rule is that acceptance criteria have to be written before the developers start work on the user story. Remember also that the acceptance criteria may be added to or refined as the development progresses and the team learns more about what they are building.

When the developers have finished the user story, they demonstrate the feature to the Product Owner, showing how each criterion is satisfied.

The benefits of acceptance criteria include:

  • focusing the team on how a feature will work from the customer’s perspective
  • removing ambiguity from requirements
  • forming the tests that will confirm that a feature is working and complete
  • limiting the developers to adding only the functionality that the user story requires.

More reading

This great post by Sandy Mamoli provides more examples of acceptance criteria.

This was the second post in our series on user stories. Next time, we’ll look at what makes a quality user story.

Tags: Posted in: Agile, User Stories 0 comments