拆分用户故事

作者 周金根

A common problem among the scrum teams that I coach is user stories that are too big. When a user story is too big, it is hard understand, estimate and implement. So what is a good size for a user story? My guidance is that the user stories at the top of the product backlog should be sized such that the scrum team could easily complete four to six stories a week.

When a team’s user stories are smaller, they complete stories more frequently. This is good on many levels. Each time a story is completed the team has delivered value, which is what the business pays us to do. We also get many types of feedback with each completed story. We can update our release (storypoint) burndown chart and get important schedule feedback, allowing us to inspect and adapt the schedule. We also get product feedback every time we finish a story. We have something new to show our stakeholders and they can give us feedback and guidance so that we can adjust the product plan, to better build the product that our stakeholders desire. Additionally, we get technical and architectural feedback. It isn’t until we have working user stories that we can see how well the technical and architectural choices we have made are serving us. If our original ideas are not working out as we had hoped, then we will need to adjust the architecture to better support the functionality that is being developed.

OK, smaller stories are better. How does a team take the big stories in its product backlog and split them into smaller stories?. I have 4 techniques that I use to split user stories, and I have yet to run across a user story that would not yield to at least one of these approaches. Someday I will find such a story, and hopefully I will learn a fifth technique.

Before applying these techniques, start by writing your story in the common user story form:

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

This isn’t the only way to write a good story, but any well-formed story can be written this way. The advantage is that writing the story in this format captures three important aspects of any good story:

  • 1. Who is this functionality for?
    This is described by the first line: As a (type of stakeholder). The more specific the stakeholder, the better the story.
  • 2. What we should create?
    This is described in second line: I want (something).
  • 3. Why is it valuable to the user?
    Yes, this is the third line of the story: So that (some value is created).

If we don’t know the “who, what, and why”- then we don’t really understand the story yet. If we don’t understand the story, then we probably can’t split it. Once we have the story in the traditional format, we are ready to begin splitting it. Tune in next week, when I’ll share the first, and easiest, of the four techniques I use to split user stories.

Splitting User Stories with Conjunctions and Connectors

So now that we have our big user stories massaged into this format, we are ready to try the first technique for splitting user stories: Conjunctions and Connectors. This is a dead-simple technique, and that’s why I always start with it. Simply read the story looking for connector words such as: and, or, if, when, but, then, as-well-as, etc.. Don’t forget that commas often function as connectors. When I see one of these connector words, I can usually split the story into two stories by separating the pieces that the connector words are holding together. Here’s an example:

As a couple planning a vacation for our family,
We want a resort that has activities appropriate for our teenage children,
as well as couples,
so that we can all enjoy our vacation.

Notice the middle line:
“We want a resort that has activities appropriate for our teenage children, as well as couples ”

We can break this into stories for the teenagers, as well as the couple.

As a teenager on vacation with my family,
I want activities to do with other teens,
so that I can meet other teens to hang out with
instead of being stuck with my lame parents the whole time.

and

As a couple traveling with my our family,
We want romantic activities to do as a couple,
so that we can rekindle our love connection.

Notice how the stories change as they get smaller. It is usually the case that when the story gets smaller, the value statement gets more specific. It’s also common for the user to be more specific, or sometimes change entirely. While it’s true that Mom wants her teenagers to have fun, we will probably be better off writing stories from the point of view of the teenager in order to satisfy this requirement. Sometimes other parts of the story get more specific as well. This is exactly what we want, as the smaller stories are not only easier to implement, but are described in more detail. This leads to a better understanding of the story, which leads to better estimates and, ultimately, an increased likelihood that the team will build the right thing.

Splitting User Stories with Generic Words

Like the first story splitting technique – Conjunctions and Connectors technique – , the second technique -the Generic Words approach works by parsing the text of the user story. This time, instead of looking for connector words, we are looking for generic words. “What’s a generic word?” you ask. Any noun that isn’t a proper noun is generic, as are many verbs, adjectives, and adverbs. What we are looking for is a generic or general term in the story which could be replaced by several more specific terms to create a number of smaller stories. Perhaps an example would help explain this:

As a couple traveling with our family,
We want romantic activities to do together,
so that we can rekindle our love connection.

In this story, the word “activities” is pretty generic. We can replace “activities” with more specific words such as: couple’s massage, romantic dinner for two, and sunset couple’s cruise. We will get these stories.

As a couple,
we want to get a couple’s massage,
so that we can relax together and reconnect.

and

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

and

As a couple,
we want to go on a couples-only cruise at sunset,
so that we can enjoy romantic moments with no children around

Splitting User Stories with Acceptance Criteria

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. 

Splitting User Stories with Timeline Analysis

This is the last of five installments in my series on splitting large user stories into smaller user stories. If your scrum team isn’t able to complete a minimum of four user stories every week, then start with the first installment and work your way back to this one. Occasionally, I find a user story that I cannot split using conjunctionsgeneric words, or acceptance criteria. When this happens, I use timeline analysis.

With this technique, I ask my stakeholder to pretend that the user story is already done, and then I ask “What happens when the functionality gets used?” They will then describe a sequence of events. Even for things that happen non-deterministically, or which could happen in parallel, they still describe it sequentially; it’s just the way our brains and our language work. I then identify the verifiable steps in the timeline. For example, if we start with this story:

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.

If I ask what happens when the diner selects their meal from the menu, someone might describe the following scenario:

I want to decide what to order at the restaurant. First I browse the menu. I like to look at pictures of the food, and read the descriptions. I’m concerned about calories, so I check the calories for the items I’m considering ordering, and then I check the prices. I also want the waiter to come and tell me about special items available that day. I really enjoy when the waiter describes the dishes in great detail, and even tells a story about why that item is the special of the day. The waiter will then go away for a bit so that I can consider my choice. When the waiter comes back, I’ll place my order.

From this timeline, we can identify several user stories.

As a diner at the restaurant,
I want a menu that lists each item with a description, price, calories and a picture,
so that I can decide which items I want to order

and

As a diner at the restaurant,
I want to be offered daily special items,
so that I can try unique dishes that aren’t usually on the menu.

and

As a diner,
I want some time to consider the daily special and the regular items before ordering,
so that I feel unrushed and happy about my final choice.

Now that you are armed with these four tools for splitting user stories into smaller stories, you may be asking “When should I use them?” Split the stories at the top of your product backlog until they are small enough that the team can comfortably complete four to six of these stories each week. As you look farther and farther down the backlog, it’s OK for the stories to be larger and larger. What you want is a gradual transition from really large epic stories near the bottom of the product backlog to those nice little stories up at the top.

There is another good reason to split stories, which is to capture early value. Imagine that we have a user story for having wireless internet access everywhere in the resort. This might take a long time to implement and cost a lot of money. We could split out a story about having wireless access in just the lobby. This story will require less time, effort and cost to implement, yet it will deliver value to those users who need occasional access to internet while on vacation. Later, we can implement the rest of the wireless internet story.

Quick Reference Guide for Splitting User Stories

We’ve been talking a lot lately about splitting user stories.

After all, one of the keys to scrum team success and happiness is properly sized stories that play nicely in a sprint. To help teams remember the four easy steps to splitting a user story, we’ve developed a quick reference guide.

Download a copy for your scrum team today!

And if you missed all the juicy details on story splitting, here are quick links to all our recent user story splitting posts.

转:Introduction to User Stories and Splitting Stories https://www.agilelearninglabs.com/2013/05/new-quick-reference-guide-for-splitting-user-stories/

Print Friendly, PDF & Email