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 conjunctions, generic 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
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.
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.
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.
- Introduction To User Stories And Splitting Stories
- Splitting User Stories With Conjunctions And Connectors
- Splitting User Stories With Generic Words
- Splitting User Stories With Acceptance Criteria
- Splitting User Stories With Timeline Analysis
- Quick Reference Guide For Splitting User Stories
- Stories To Practice On
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.