There’s no way you can slice through something that doesn’t deliver value and end up with something that does. If you bring me a big piece of lettuce, there’s no way we’re slicing that into a cheeseburger.
In this episode of the Humanizing Work Show, we tackle one of the most-requested topics in Agile and Scrum: how to split a user story effectively. Drawing from our best-selling 80/20 Product Backlog Refinement course, Richard walks through the widely-used Story Splitting Flowchart, breaking down common challenges and actionable solutions.
You’ll learn:
- Why “unsplittable stories” are often just non-stories
- How to balance the INVEST criteria when refining your backlog
- Which story splitting patterns are most useful (and when to use them)
- How smarter story slicing improves prioritization and ROI
Whether you’re a Product Owner, Scrum Master, Agile Coach, or team member, this episode will help you refine your backlog with confidence and clarity.
Resources Mentioned:
Episode transcription
Peter Green
This week we were brainstorming topics for future episodes of the show. We usually have dozens of ideas, and we had plenty of cards at the top of the “To Script” column in our kanban board. But just for fun, I decided to ask ChatGPT to look at our website and our YouTube channel and suggest topics, just to see if there were any blind spots.
And as it turns out, there was a pretty big one! The first suggestion from ChatGPT was that we do an episode on story splitting. Then I thought, “Wait, we’ve done 170 episodes and not one of them is on how to split a user story?” Our guide to Story Splitting is the most accessed content on our site, and has been for a while. Richard’s story splitting poster has been downloaded well over a million times and has been translated into 13 languages.
Then I realized why I thought we’d done an episode on story splitting. A couple years ago, we took all of our best tools for story splitting, backlog management, planning, and estimation, and produced a really high-quality online course called 80/20 Product Backlog Refinement. The process of writing, shooting, editing, and animating that content must have stuck in my head as “we’ve already done this.”
So that brings us to today’s episode. We’re going to share an except from the 80/20 course where Richard walks through the famous Story Splitting poster. And we’ll pause the video a few times for some commentary to fill in some blanks, since that video refers to other lessons in the course.
Richard Lawrence
Before we dive into that, though, a quick reminder, that the Humanizing Work Show is a free resource sponsored by the Humanizing Work company, where we help organizations get better at leadership, product management, and collaboration in a complex world. Visit the contact page on our website, humanizingwork.com, and schedule a conversation with us if you and your organization would benefit from stronger results in those areas.
Peter
If you want to support the show, the best thing you can do if you’re watching on YouTube is subscribe, like the episode, and click the bell icon to get notified of new episodes. Drop us a comment with your thoughts on today’s topic. If you’re listening on the podcast, a five star review makes a big difference in whether other people find it or not.
Ok, let’s get into this video from the course. Here’s Richard from the 80/20 Product Backlog Refinement course…
Richard
The flowchart has three parts. First, we make sure we have a real story or feature to start with. We need a complete slice of value if we’re going to find smaller valuable slices inside it. Sometimes people come to me with what they think is an unsplittable story, which turns out to be just an architectural component or task. Not an actual user story with real value. There’s no way you can slice through something large that doesn’t deliver direct value and end up with something smaller that does. So, the first step in splitting a story is sometimes actually making it larger by combining it with the rest of the components it needs to become a slice of value.
Peter
Ok, this line really stood out to me: You say something like, “There’s no way that you can slice through something that doesn’t create value, and end up with something that does.” It’s so obvious when you say it out loud, but starting with some piece of work that clearly adds value is so often overlooked!
Richard
Ya, when I wrote the original “Patterns for Splitting User Stories” article that led to the story splitting flowchart, I finished the article with a challenge to bring me your unsplittable stories. I wasn’t sure if they existed, or if there were some patterns we hadn’t discovered, so, I wanted to see some examples. And, overwhelmingly, the most common reason they can’t be split into good stories is that they’re not an increment of value to begin with.
To give kind of a silly analogy… If you have a big cheeseburger—the bun, the meat, the cheese, the lettuce, tomato, pickles, maybe some mayo—you can slice that into smaller cheeseburgers with all that good stuff in each one. But if you bring me a big piece of lettuce…there’s no way we’re slicing that lettuce into a cheeseburger. My ducks might enjoy eating it, but I’m gonna be sad about that “burger.”
So, don’t be afraid to take all of those architectural components and tasks and put them back together into something valuable and then try slicing it a different way into real stories.
Peter
All right. Now with renewed hunger for some lunch, let’s go, back to the lesson…
Richard
The first question on the flowchart asks, Does the story satisfy INVEST, except perhaps small. If you don’t remember what the INVEST attributes means, stop and go back to the previous lesson and review that. It’s important.
Peter
Ok, in this section, Richard, you mention very briefly the INVEST acronym, and we’re not going to rehash the whole idea of INVEST from Bill Wake here, most of our listeners will either be familiar with it or can look it up. I do want to point out one of the big insights from the 80/20 lesson on INVEST, though, which is this tension between INV, which is easiest to meet when the story is big, and EST, which is easiest when the story is small. How do you address that tension, Richard?
Richard
Briefly, EST matters more at the top of the backlog—It’s the time when our team is trying to make concrete plans, so we care a lot about things being small enough to fit into a sprint, we care a lot about being able to estimate and plan reasonably accurately, we care about being able to test that the work is done. You go further out, and INV matters more. Bigger slices with clear, independent value and plenty of room for learning and for conversations.
As items move up the backlog and you slice big things into smaller ones, you just naturally trade INV for EST and that’s OK.
Peter
Ya. That trade-off makes a ton of sense.
So let’s get to the actual patterns from the poster.
Richard
Once we have a decent, if large, story to start with, we move to part two, applying the story splitting patterns. These patterns describe several common kinds of functional complexity and useful ways to split through them.
Peter
All right, Richard, so, there are 9 patterns in the poster–in your experience, is there one that people should learn first, or explore, or is it really too context specific to suggest one or the other?
Richard
I often teach the workflow pattern first—and it says “start here” on the poster at the workflow pattern for a reason, you’re trying to find a thin slice across the complex part of a workflow—partly because workflows are all over the place in software systems of all kinds, and because they’re easy to split wrong, but also because the workflow pattern really nicely illustrates the meta-pattern behind all the patterns.
Find the complex part. List the variations through the complex part. And then, for each of those rules or entities there are many of, narrow that variation down to one. Then, story by story, expand the “ones” back to “manys” to handle the whole range of the cases.
There’s a whole video about this in the 80/20 Product Backlog Refinement course.
Peter
All right, back to the lesson. This next section gives a fantastic real example of the 80/20 principle that the course is named after, and how it applies to product backlog refinement. I think if our listeners just did what you describe next, they’ll save their team and their business a ton of wasted effort.
Richard
Finally, once we’ve applied some of the patterns to end up with possible splits, we’ll evaluate the splits to see if we found a good one. So Step three, ask several questions to evaluate the split. Most of the questions here are pretty straightforward, but I want to call your attention to one that is less obvious. I ask, “Are there stories you can deprioritize or delete?” Here’s why. Every feature story has high value and low value parts. One of the benefits of splitting is finding the low value parts and never building them. Thus, if you get a split that doesn’t have low value parts, you may have low value parts hiding across your smaller stories, and it’s worth trying a different pattern to see if you can find that waste. For example, imagine you have a feature for searching for products in an online store, and the way you have designed the search user interface is unique and clever, but maybe more clever than it needs to be. Finding a product to buy is the high value part of that feature. Searching with the clever UI may be a nice enhancement, but it’s clearly lower value than the core search behavior. If you split that search feature into stories for searching by different attributes, like product name, key word, category, color, etc., but keep the overly clever UI in each story, it’s hard to see something that clearly can be deprioritized. The lower value part of the original feature is spread across the smaller stories. But if we split off the fancy UI as an enhancement of its own, into its own story, we can prioritize the fancy UI below the core search behavior, and perhaps the less important attributes to search by get prioritized even lower. So a good split gives us options for prioritizing by value more clearly.
Peter
That’s gold, Jerry! I’ve seen that pattern save my team whole sprints worth of work, when we finally got good at splitting into smaller slices that still had value, then we could make priority decisions about small slices of value, and that’s where a Product Owner can have huge leverage to create ROI compared to more traditional approaches to splitting up work.
Ok, let’s get to this last section.
Richard
Often there’s some back and forth between steps two and three. You try a pattern at step two, and then use the questions at step three, to see if it worked well, and if it didn’t, try another pattern. Sometimes you’ll find a combination of patterns actually gets you the best result. Maybe you start with an operation split and discover that one of the operations is still large, and so you apply a business rule split to that part.
Well, that’s the high level overview of the flowchart, and how to use it, continue onto the next few lessons for a deeper dive into each of the splitting patterns.
Peter
Ok, if any of you watching on YouTube or listening to the podcast want to do what Richard said there, in that last section, continue on to the next lessons exploring the other patterns, you can check out the course at humanizingwork.com/8020
Richard
Story Splitting has proven to be a keystone habit for agile teams. It’s a skill that enables Product Owners to maximize the flow of value, teams to see regular meaningful progress every day, and the business to realize a return on investment early and often.
Thanks for tuning in to today’s episode!
Last updated