Splitting User Stories with Acceptance Criteria

This is the fourth part of my series on splitting user stories. If you are just joining us, start with the first installment and work your way forward from there. Today’s technique is the third of four techniques to split user stories and it makes use of the user story’s acceptance criteria in order to split the story into smaller stories. What are acceptance criteria? Acceptance criteria are a list of pass/fail testable conditions that help us determine if the story is implemented as intended. Each user story should have between 4 and 12 acceptance criteria. The product owner works with the team to create, agree-upon, and record the acceptance criteria for each user story before the story enters a sprint.

Let’s look at an example. Here is a user story:


As a couple,
we want a romantic dinner for two,
so that we can have a date even more romantic than our first date

Here are some acceptance criteria for this story:

  • There are 2 lit candles and fresh flowers on every table
  • The main course offerings include steak, fish, and at least one vegetarian option
  • There are at least 2 kinds of red wine and 2 kinds of white wine available, as well as a Champagne
  • There is a string quartet or a piano player playing soft instrumental music
  • The waiters are wearing tuxedos

If we examine each one of the acceptance criteria, we can ask “Who wants this?” The answer to this question becomes the user in “As a (type of stakeholder).” Next, we ask “Why do they want that?” The answer to this question identifies the value in “so that (some value is created).” The body of the acceptance criteria provides the “I want (something)” part, and now we have all three parts for our new user story:


As a (type of stakeholder),
I want (something),
so that (some value is created).

Here are user stories that could be derived from the acceptance criteria above.

As a couple on a dinner date,
we want candles on the table,
so that the mood will be more romantic.

and

As a diner in the restaurant,
I want to be able to choose from steak, fish, and at least one vegetarian option,
so that I can order something that conforms to my dietary and flavor preferences.

and

As a wine lover
I want at least 2 kinds of red wine, 2 kinds of white wine and 2 Champagnes available,
so that I can choose a wine that will go well with my meal.

and

As a couple on a dinner date,
I want to hear instrumental music from a string quartet or a piano player,
so that the mood will be more romantic and I can still converse with my date.

and

As a couple on a romantic dinner date,
I want waiters that are wearing tuxedos,
so that we can feel like we are at a classy restaurant.

Using acceptance criteria to identify smaller sub-stories is very handy and powerful, because it is recursive. Every story needs acceptance criteria, and many acceptance criteria can become their own smaller stories. Of course, each of these new small stories needs to have acceptance criteria. And, we could use these acceptance criteria to break the stories down again. It’s turtles all the way down!

Tune in next week for the final installment in Splitting User Stories.

Here are quick links to all of the user story splitting posts.

Cheers,

Chris

Chris Sims is co-author of Elements of Scrum as well as a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness.

This entry was posted in agile. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

2 Comments

  1. ronald
    Posted July 14, 2016 at 4:12 am | Permalink

    The way you detail the acceptance criteria into user stories, more looks like these are (just) requirements.
    How would you mark the difference between acceptance criteria and requirements?

    • Posted September 9, 2016 at 10:20 am | Permalink

      The terms “user stories” and “requirements” can be used interchangeably. If we have user stories, with acceptance criteria, in our product backlog, those are our requirements. There is some deeper subtlety though. The word requirement seems to carry a notion that we have to build it. Much better to think of the things in our product backlog as requests, that we should consider building. Ultimately, the product owner is responsible for deciding which of these is worth building and which are not.

      I hope that helps!

      Chris

5 Trackbacks

  1. [...] User Stories with Conjunctions and ConnectorsSplitting User Stories with Generic WordsSplitting User Stories with Acceptance CriteriaSplitting User Stories with Timeline AnalysisHappy splitting! Laura This entry was posted in [...]

  2. By Splitting User Stories with Timeline Analysis on July 1, 2013 at 5:16 pm

    [...] and other members of our team. Questions, comments, and invitations to lunch are always welcome!« Splitting User Stories with Acceptance CriteriaQuick Reference Guide for Splitting User Stories »Splitting User Stories with Timeline [...]

  3. […] business value sliver. He has four techniques: Conjunctions & Connector Words, Generic Words, Acceptance Criteria, Timeline […]

  4. By Ten Powerful Questions for Discovering Acceptance Criteria | Beyond Requirements on December 28, 2015 at 10:08 pm

    […] posts discussing different story splitting techniques.  One technique he described in the post Splitting User Stories with Acceptance Criteria was how to use questions to identify the parts of new user stories that can be identified from the […]

  5. […] posts discussing different story splitting techniques.  One technique he described in the post Splitting User Stories with Acceptance Criteria was how to use questions to identify the parts of new user stories that can be identified from the […]

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>