Peter: This week we were brainstorming topics for future episodes of the show, and we usually have dozens of ideas, and we had plenty of cards at the top of our 'To Script' column in our kanban board. But just for fun, I decided to ask Chat GPT to look at our website and our YouTube channel and suggest topics just to see if there are any blind spots.
And as it turns out, there was a pretty big one. The first suggestion from Chat GPT was that we do an episode on story splitting, and 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 it 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 gonna share an excerpt 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: 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, humanizing work.com and schedule a conversation with us if you and your organization would benefit from stronger results in those areas.
Peter: And if you wanna 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. And if you're listening on the podcast, a five star review makes a big difference in whether other people find it or not.
Okay, 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 uns splittable 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: Okay. 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: Yeah. When I wrote the original Patterns for Splitting user stories article that led to the story splitting flow chart, I finished the article with a challenge to bring me your unssplittable 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 a kind of silly analogy, if you have a big cheeseburger, you got the bun, the meat, the cheese, the lettuce, tomato, pickles, maybe some mayo. You could 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 in a different way into real stories.
Peter: All right, now with renewed hunger for some lunch, back to the lesson.
Richard: The first question on the flow chart asks, does the story satisfy invest except perhaps small? If you don't remember what the invest attributes mean, stop and go back to the previous lesson and review that. It's important.
Peter: Okay. In this section, Richard, you very briefly mentioned the Invest acronym, and we're not gonna rehash the whole idea of invest from Bill Wake here.
Most of our listeners will either be familiar with it or they can look it up. I do wanna point out one of the big insights from the 80 20 lesson on the on Invest, though, which is this tension between I and V, which is easiest to meet when the story's big and EST, which is easiest when the story is small.
Now, 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 okay.
Peter: Yeah, that trade off makes a ton of sense. Okay, 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 nine different patterns in the poster. In your experience, is there one that people should learn first or explore, or is it really two 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 so that you're trying to find the thin slice across the complex part of a workflow.
Partly because workflows are all over the place in software systems of all kinds. 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's many of narrow that variation down to one.
And then story by story, expand those ones back to many's to handle a whole range of cases. There's a whole video about this in that 80 20 product backlog refinement course
Peter: Allright, 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 described 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 asks several questions to evaluate the split.
Most of the questions here are pretty straightforward, but I wanna call your attention to one that's less obvious. I ask, are there stories you can deprioritize or delete? Here's why every feature or 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 a low value part, 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've 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, keyword, category, color, et cetera, 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 sprint's 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. Okay, 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, then discover 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: Okay. 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
[email protected] slash 8 0 2 0 80 20.
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 into today's episode.
