User stories: a beginner’s guide to acceptance criteria

Last week I described the bones of the user story. 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:

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

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.

Stay tuned for our blog post, where I’ll talk about how user stories get used in the development process, from the perspective of the Product Owner.

Related Posts:

9 Comments

  1. Nícolas
    Aug 11, 2011 @ 17:18:22

    Greetings!

    Acceptance criteria or acceptance test is a very useful way to measure development progress in a software project.

    It’s amazing when you can explain to the customer what are you working on just describing the acceptance criteria.

    I’m used to use the word “scenario” instead of acceptance criteria, I think it’s more friendly.

    When describing scenarios I like to use the pattern Given/When/Then. This pattern avoids a lot of duplicity between scenarios.

    Linking this post with the story mapping post you wrote, while doing the requirements workshop, you suggest to the tech team to estimate the user stories.

    Don’t you think an user story is too abstract to get an estimation?

    I have a feeling that scenarios gives to tech people more accuracy to estimate.

  2. courtney courtney
    Aug 11, 2011 @ 17:50:31

    Hey Nicolas

    Thanks for getting in touch. I’ve not used the Given/When/Then approach, but I’m tempted to give it a whirl.

    In response to your question; first up, we don’t usually talk about the ‘tech team’ – the team is the team, and usually involves people doing wireframes, design, and sometimes content as well as development.

    We estimate in story points. If you have a well understood done definition, and user stories with good acceptance criteria (regardless of how they’re written) that should be just what the team needs to do an estimate in story points.

    We then follow up the estimate with tasks specific to that story, estimated in hours. This is another check point for us to make sure the story estimate seems appropriate – a story sized as a 2, but with 30 hours of tasks attached, probably needs to have the estimate reviewed.

  3. 37 Tasks for a Product Owner’s Job » Agile Trail
    Nov 30, 2011 @ 00:17:58

    […] acceptance criteria for each user story […]

  4. Gus
    Dec 21, 2013 @ 02:15:32

    You’ve put “An an actor…”

  5. Kirstin Kirstin
    Jan 08, 2014 @ 15:44:24

    Thanks Gus -we’ve now ammended

  6. Dave Schinkel
    Aug 14, 2014 @ 12:34:39

    you are missing one critical set of details at a top level in your acceptance criteria and that is inputs / outputs

    For software development, it’s even helpful to have an example querystring or JSON in your description of your story. not saying you need to put all low-level implementation details but just something to start and to go by. That’s what we do and it helps dramatically.

    Your points above are way too general in the acceptance criteria, it needs to be much more specific including business rules, etc. expected.

  7. Dave Schinkel
    Aug 14, 2014 @ 12:35:50

    also I may add that if your stories require too much description THEY ARE WAY TOO BIG. Always split into smaller stories if possible. Smaller the better as you can get them done, and you don’t end up with stories that never end.

  8. Gavin Gavin
    Sep 26, 2014 @ 16:36:02

    Hi Dave. Agreed to your point about splitting stories, we always recommend splitting up stories when possible, it’s a great practice for a team to get accustomed to.

  9. Gavin Gavin
    Sep 26, 2014 @ 16:37:15

    Hi Dave, we would consider adding other information, such as inputs and outputs, as attached notes to a story, rather than the acceptance criteria themselves.

Leave a Comment

*