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

We examine each of the acceptance criteria, and ask: “Who wants this?”
The answer to this question becomes the stakeholder 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 <the deliverable>” part, and now we have all three parts for our new user story:

As a <type of stakeholder>,
I want <the deliverable>,
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 Sims

Share it!

7 thoughts on “Splitting User Stories with Acceptance Criteria

  1. Pingback: New! Quick Reference Guide for Splitting User Stories

  2. Pingback: Splitting User Stories with Timeline Analysis

  3. Pingback: Per Aspera Ad Astra – Agile 2015 Review | An agile mind

  4. Pingback: Ten Powerful Questions for Discovering Acceptance Criteria | Beyond Requirements

  5. ronald

    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?

    Reply
    1. Chris Sims Post author

      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

      Reply
  6. Pingback: Ten Powerful Questions for Discovering Acceptance Criteria - KBP Media -

Leave a Reply to ronald Cancel reply

Your email address will not be published. Required fields are marked *