What Is Story Splitting
Story splitting is the act of examining a large backlog item and splitting it into smaller backlog items that provide value and can be delivered in a short time frame.
You can consider story splitting to be a planning technique that helps you organize your backlog into manageable chunks. You can also think of it as an analysis technique that helps you understand a particular backlog item through the act of splitting it into smaller, valuable backlog items.
Story splitting also goes by the name story slicing.
Note: While the name story splitting is derived from splitting user stories, this technique brief uses the more general term backlog item. I chose to use the more general term because user story really refers to a particular approach to expressing backlog items, but this technique applies to all different types of items that may exist on your backlog.
When to use Story Splitting
Story splitting usually occurs as a part of backlog refinement. As you get backlog items ready to start development work, your team may realize that a given backlog item is “too big” and you need to split it into smaller bits. As a result, story splitting is one of the key activities that occurs during backlog refinement.
You may also use story splitting to identify the backlog items needed to deliver a given feature. This usually occurs as you start work on a new feature or want to solve a new problem.
It’s a good idea to have a backlog with a small number of features that have meaning to your customers. You only split those features into stories when you’re getting ready to deliver that feature. As a result, your team will use story splitting on a regular basis.
Why use Story Splitting
Smaller backlog items are easier to understand
Smaller backlog items are less complicated, so there is less chance for misunderstanding of what is/is not included in the story.
Story splitting identifies aspects of a backlog item that are not needed
If your team splits a backlog item appropriately, you may find that some of the smaller backlog items are not essential to delivering the outcome expected from the larger backlog item. For example, if a backlog item was split along different scenarios, some scenarios may not be as relevant, or even happen. Your team can save time by not addressing those scenarios.
Smaller backlog items provide a faster feedback loop
You can deliver smaller backlog items sooner, which means your team can get feedback sooner, and if you took a wrong path, you were “wrong for less time.”
Smaller backlog items increase progress
Smaller backlog items take less time to finish, which means it’s easier to see progress.
How to Split Stories
Story splitting consists of two basic steps:
- Identify backlog items that need to be split.
Backlog items generally are candidates to be split when they will take too long to deliver as they currently stand. “Too long” may mean longer than the length of an iteration if your team is using a framework such as Scrum or SAFe.
“Too long” may mean that it takes longer to deliver than your team is comfortable waiting for feedback.
- Identify the pattern(s) you want to use to guide your split.
There is a slew of different approaches that people have identified for splitting backlog items. As a result of some extensive research, I’ve identified 21 story splitting patterns.
Here’s a pdf copy of the 21 Story Splitting Patterns.
When trying to decide which pattern(s) keep the following rules of thumb in mind:
- Choose the split that lets you deprioritize or throw away one or more backlog items
- Chose the split that eliminates or at least reduces dependencies
- Choose the split that gets you more equally sized small backlog items
Caveats and Considerations
You may find that you can use multiple story splitting patterns in succession to get to your preferred backlog item size. For example, you may start with a Create, Read, Update, Delete pattern. Then you may split the create backlog item up into smaller backlog items that address different scenarios.
There are some patterns which should be considered patterns of last resort, meaning you only use these when you’ve ruled out all other patterns. An example of a pattern of last resort may be deferring error handling or logging if including error handling is part of your team’s definition of done.
Additional Resources
The Humanizing Work Guide to Splitting User Stories
Richard Lawrence and Peter Green consolidated and updated all of their story splitting content into this new guide. This includes some of the “better ways” they’ve discovered in the last decade and a half of coaching clients to split their backlog items in a wide variety of contexts.
Why you want to split user stories
I explain why you want to split user stories and provide some references on how to do it. After all, Epics are for customers, user stories are for the team.
The SPIDR technique for splitting backlog items
Many teams tend to leave their backlog item way too big to be completed faster. Working on small backlog items helps your team to get a fast feedback loop, as they can be completed faster, the product owner, stakeholders and customers can test and give feedback as soon as possible, which will help the team to easily improve and correct things quicker.
This video from OeLean explains the SPIDR technique for splitting backlog items. SPIDR stands for Spike, Paths, Interface, Data, and Rules.
How To Refine Features
You can get a lot of value out of having big items on your backlog (ie features) because you can get a broad view of the overall output you might need to deliver without having to dive into detail on any one particular item too soon.
At some point, though you do need to dive into detail on something in order to start delivery. Feature refinement provides a way to do that in a way that allows you consider options and focus on the essential aspects of the feature and discard the aspects that aren’t completely necessary.