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. The first 3 techniques I shared are my favorites, and I manage to split 95% of stories using those 3 techniques. Occasionally, I find a user story that I cannot split using conjunctions, generic words, or acceptance criteria. When this happens, I resort to 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, a user might describe this 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.


This technique works equally well for stories with a traditional user interface, or those that are very low-level and technical. Do be careful with this technique; it is easy to lose sight of the user and the value and then fall into technical decomposition instead of true story splitting. To combat this, write your new stories in the traditional format:

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

If you can find your stakeholder and your value, then you are probably doing OK. This extra level of required care is why I use the timeline analysis as a last resort. The other techniques: conjunctions and connectors, generic words, and acceptance criteria all have the advantage of keeping you in the “As a, I want, so that” format automatically. You almost can’t go wrong.

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.

OK, that wraps up this series on splitting user stories. Have comments or questions? Know a great technique that I didn’t present? Please leave a comment!

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.

One Comment

  1. Rich Gierak
    Posted November 12, 2015 at 7:04 pm | Permalink

    Hey Chris,
    Great series on story splitting, I’ll be sharing with my teams as we strive to get small. Peace, Rich.

2 Trackbacks

  1. […] Your Stories are Too Big! by Chris Sims (@ChrisSims) – Chris gave a great presentation on techniques he has used successfully with teams to break stories into small slivers of business value. I loved Chris’ comment, “I want to get teams addicted to DONE!” To help this he suggests getting teams to complete 4-6 stories a week. How do you do that? Use many of the methods in his presentation to break down a story into its smallest business value sliver. He has four techniques: Conjunctions & Connector Words, Generic Words, Acceptance Criteria, Timeline Analysis. […]

  2. […] 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. Read more at agilelearninglabs.com […]

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>