How to Split User Stories
Working from a prioritized backlog of small user stories allows a team to get value and high-quality feedback on frequent intervals. Many teams struggle to split large user stories into small stories in a useful way. Instead of ending up with small vertical slices through their architecture, they get stories that look more like tasks or architectural components and fail to experience the value or feedback small stories should provide.
Patterns for Splitting User Stories outlines 9 kinds of functional complexity in large stories and approaches to split through each one. It has a cheat sheet of example stories for each pattern. How to Split a User Story poster walks through the questions used when coaching a team to split their own stories.
Story Splitting Flowchart available to download
Want to know how story splitting relates to scale? Check out Vertical Slices and Scale.
Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model.
Many new agile teams attempt to split stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy small, but it fails at independent and valuable.
Over my years with agile, I’ve discovered nine patterns for splitting user stories into good, smaller stories.
(Note: As with any pattern language, I didn’t invent these patterns, I’ve just observed and compiled them. For example, this great post by Lasse Koskela put names on some patterns I’d observed but not named, especially “Major Effort.”)
How Small?
How small should stories be? I recommend 6-10 stories per iteration, so how small is small enough depends on your team’s velocity. Before your next planning meeting calculate what estimate should trigger splitting a story. For most teams, it seems to be 8 or 13 points. But on a recent project I’m doing by myself, I’ve needed to split 5-point stories.
When you’re in a planning meeting and you hit your trigger estimate, pull out the cheat sheet at the end of this article and try a few of the patterns until you find a good split.
Which Pattern to Use
You’ll often find that you can split a story using several of the patterns. Which split should you choose? I use two rules of thumb:
Choose the split that lets you deprioritize or throw away a story. The 80/20 principle says that most of the value of a user story comes from a small share of the functionality. When one split reveals low-value functionality and another doesn’t, it suggests that the latter split hides waste inside each of the small stories. Go with the split that lets you throw away the low-value stuff.
Choose the split that gets you more equally sized small stories. The split that turns an 8 point story into four 2 point stories is more useful than the one that produces a 5 and a 3. It gives the Product Owner more freedom to prioritize parts of the functionality separately.
Pattern #1: Workflow Steps
Here’s a story from a content management system one of my clients was creating:
As a content manager, I can publish a news story to the corporate website.
Didn’t sound too big—until we dug into the workflow to get a story published. It turned out that just to get a few sentence news story on the corporate website required both editorial and legal approval and final review on a staging site. There’s no way 6-10 stories like this would fit in an iteration.
In a workflow like this, the biggest value often comes from the beginning and end. The middle steps add incremental value, but don’t stand alone. So it can work well to build the simple end-to-end case first and then add the middle steps and special cases.
The new stories included:
…I can publish a news story directly to the corporate website.
…I can publish a news story with editor review.
…I can publish a news story with legal review.
…I can view a news story on a staging site.
…I can publish a news story from the staging site to production.
Sometimes, though, the whole workflow matters, so you can’t just start with the beginning and end. In those situations, look for a thin slice through the whole workflow. Maybe it supports the most common case. Maybe you hard-code or otherwise simplify the best understood parts of the workflow to you can explore the more complex parts.
Either way, the most obvious split—one step at a time from beginning to end—is the wrong way to go. Check out this excerpt from my 80/20 Product Ownership course for more on why the obvious split is wrong and how to use the other two approaches.
Pattern #2: Business Rule Variations
This story has a few equally complex stories hidden within it that accomplish the same thing using different business rules:
As a user, I can search for flights with flexible dates.
Digging into “flexible dates” reveals several different business rules, each of which can be a good story on its own:
…as “n days between x and y.”
…as “a weekend in December.”
…as “± n days of x and y.”
Pattern #3: Major Effort
Sometimes a story can be split into several parts where most of the effort will go towards implementing the first one. For example, this credit card processing story,
As a user, I can pay for my flight with VISA, MasterCard, Diners Club, or American Express.
could be split into four stories, one for each card type. But the credit card processing infrastructure will be built to the support the first story; adding more card types will be relatively trivial. We could estimate the first story larger than the other three, but then we have to remember to change our estimates if the Product Owner later changes priorities. Instead, we should defer the decision about which card type gets implemented first like this:
…I can pay with one credit card type (of VISA, MC, DC, AMEX).
…I can pay with all four credit card types (VISA, MC, DC, AMEX) (given one card type already implemented).
The two new stories still aren’t independent, but the dependency is much clearer than it would be with a story for each card type.
Pattern #4: Simple/Complex
When you’re in a planning meeting discussing a story, and the story seems to be getting larger and larger (“what about x?”; “have you considered y?”), stop and ask, “What’s the simplest version of this?” Capture that simple version as its own story. You’ll probably have to define some acceptance criteria on the spot to keep it simple. Then, break out all the variations and complexities into their own stories. So, for example, this story,
As a user, I can search for flights between two destinations.
stays simple by splitting off variations like,
…specifying a max number of stops.
…including nearby airports.
…using flexible dates.
…etc.
Pattern #5: Variations in Data
Complexity in a story can come from handling variations in data. For example, a system I’m currently working on needs to model geographic areas served by transportation providers. We could have burned our whole project budget just handing geography; it’s potentially that complex. When I talked through the story,
As a user, I can search for transportation providers by trip origin and destination.
with our Product Owner, I discovered that, while we didn’t need full-fledged GIS, modeling geography would still be quite complex. We stopped and asked, “What’s the ‘good enough’ way to model geography so we can build other high-value features now?” We settled on,
As a user, I can search for transportation providers by trip origin and destination as counties.
This worked for a while, until we collected more data and found that some providers only served certain cities or even neighborhoods. So a new story came up:
As a user, I can search for transportation providers by trip origin and destination as counties, cities, towns, or neighborhoods.
Looking over the new provider data, we also discovered that some providers will support trips originating in a single city but ending in any number of surrounding cities. This led to the story:
Providers can serve different geographic areas for trip origin and destination.
All three of these stories are split from the original geography story. The difference here is that we added stories just-in-time after building the simplest version. But sometimes you know the data variations up-front. The classic example is localization:
As a content manager, I can create news stories.
…in English.
…in Japanese.
…in Arabic.
…etc.
Pattern #6: Data Entry Methods
Complexity sometimes is in the user interface rather than in the functionality itself. In that case, split the story to build it with the simplest possible UI and then build the more usable or fancier UI. These, of course, aren’t independent—the second story effectively is the original story if you do it first—but it still can be a useful split.
As a user, I can search for flights between two destinations.
…using simple date input.
…with a fancy calendar UI.
Pattern #7: Defer Performance
Sometimes, a large part of the effort is in making a feature fast—the initial implementation isn’t all that hard. But you can learn a lot from the slow implementation and it has some value to a user who wouldn’t otherwise be able to do the action in the story. In this case, break the story into “make it work” and “make it fast”:
As a user, I can search for flights between two destinations.
…(slow—just get it done, show a “searching” animation).
…(in under 5 seconds).
Pattern #8: Operations (e.g. CRUD)
The word “manage” in a user story is a giveaway that the story covers multiple operations. This offers a natural way to split the story. For example:
As a user, I can manage my account.
…I can sign up for an account.
…I can edit my account settings.
…I can cancel my account.
Pattern #9: Break Out a Spike
A story may be large not because it’s necessarily complex, but because the implementation is poorly understood. In this case, no amount of talking about the business part of the story will allow you to break it up. Do a time-boxed spike first to resolve uncertainty around the implementation. Then, you can do the implementation or have a better idea of how to break it up. Don’t know how to implement the following story?
As a user, I can pay by credit card.
Then, break it into:
Investigate credit card processing.
Implement credit card processing.
In the “investigate” story, the acceptance criteria should be questions you need answered. Do just enough investigation to answer the questions and stop; it’s easy to get carried away doing research.
The spike split is last because it should be your last resort. You probably know enough to build something. Do that, and you’ll know more. So, make every effort to use one of the previous eight patterns before resorting to the spike pattern.
Conclusion
Resist the temptation to split an overly large user story by architectural layers. Instead, try these patterns to split your story into smaller stories that still satisfy the INVEST model. Let me know how it works for you or if you’ve run into unsplittable stories (I love a challenge!).
Reference Material
Videos
Story Splitting Cheat Sheet
