User stories are perfect for breaking large and complex projects into incremental steps. However, finding the best way to split stories so that they fit into a single iteration is a problem that plagues many agile teams.
If you don’t split stories correctly, it throws off your velocity and estimates, and makes it harder to demonstrate progress during a review.
Why Do Teams Struggle to Split User Stories?
The most likely reason teams struggle with how to split user stories is that they don’t use a consistent system. This isn’t surprising to me and it’s not really the fault of the team.
If you search online for “how to split user stories,” you face an overwhelming number of options. Finding twenty ways to split a story may seem great at first. But you’ll probably find that many of those rules overlap with, or even conflict with one another. And trying to remember and evaluate twenty different story splitting strategies can certainly slow discussions down.
So, what are successful agile teams doing instead?
Many teams rely simply on their own intuition and experience to split stories. This can be OK at times. But I far prefer having a system or repeatable approach that I know will lead me to a good way of splitting a story.
The other advantage to having a system–as I show in the video–is that you can roll it out to other teams. It’s hard to scale an approach that relies solely on intuition and experience.
Not being able to split stories well also makes it hard to estimate them, which happened to Better User Stories member, Michael B.
Michael works for a consumer products company implementing e-commerce capabilities. He explained that while it initially seemed quicker to split stories using gut instinct, it created problems later:
“We’d always struggled to split large stories and get good information, particularly at the low-level. Our user stories would capture a need, but then we’d eventually need to break it down further, only to find hidden information. As a result, we were underestimating how long work would take.”
– Michael B.
Better User Stories Member
Once he had a system in place, Michael was able to change this:
“By splitting stories more effectively, there is more thinking about the purpose of the story and the result is we’re estimating more accurately.”
Solving the Story Splitting Headache: What You’ll Learn in This Video
After years of working with user stories, helping teams with them, and studying what was helping teams succeed, I realized that an effective system for splitting is actually easier than most people think.
In fact, everything you need to know to split a story can be distilled into the simple approach I’m sharing with you today.
Watch the video today and discover how these 5 strategies for splitting stories can help teams reduce surprises, balance technical requirements and end-user value, and produce something shippable and valuable every iteration.
Splitting Stories the Right Way Reduces Surprises
Once the team begins work on a story, you don’t want too many surprises. Conversations, yes; but not conversations that uncover so many unknowns that progress stalls or even stops.
If you split stories and leave them still too big, iteration planning takes longer and velocity is more variable as the team is often only 90% done with a story when the iteration ends.
Discovering too late in an iteration that a story is too big can affect not just that one user story but the entire iteration:
“As we started working on a story, we would sometimes see that it actually needed to be more than one story and would need splitting out. However, because of the code management system we use, it’s much harder to do that and keep tasks linked together once you’ve started. It makes it really difficult to split after the fact and still trace everything.”
Better User Stories Member.
But that doesn’t mean you should go to the opposite extreme and have infinitely small stories. Do that and your user stories begin to look like a list of tasks.
While it might be easy to complete extremely small stories in an iteration, it can make them harder to manage and prioritize.
The five story-splitting approaches outlined in the video show you how to avoid obstacles that may be hiding in a large story without saddling the team with a long list of technical tasks.
How to Keep Technical Requirements Without Losing Sight of End-User Value
Splitting stories that focus on end-user value is all good and well, but you still need a good idea of what the system needs to do, before you can work on it. Fortunately, splitting user stories doesn’t have to be a choice between keeping the development team or stakeholders happy. You can still split stories to be small enough for the team yet big enough that stakeholders can understand their value.
In this video, I show you how to build a graphical representation of customer needs and system requirements. It’s very similar to the story-mapping process I outlined in video one of this free training series. (Missed video one? Sign up and watch it here).
Developing this at-a-glance layout of customer-driven functionality makes it much easier to split stories effectively. It highlights interdependencies so that instead of splitting along technical boundaries (such as frontend or backend work) you can see the stories needed to deliver the feature from a customer’s point-of-view. You can also use this process to know which stories of a feature can be deferred to another iteration (while still adding value) so that you’re bringing in just the right amount of work.
Which brings me to the next thing you’ll learn in this video: Splitting Stories the Right Way Helps Demonstrate Meaningful Progress
Teams can feel held hostage to the goal of delivering something potentially shippable by the end of each iteration. In fact, some teams have told me it’s just plain impossible for their products.
But, the five techniques I cover in this video will tell you exactly how to achieve something potentially shippable and of value to stakeholders–even if you’ve thought doing so is impossible on your product.
Splitting stories with these techniques allows you to go into every iteration review confident you have a set of completed features that is worth demonstrating to stakeholders.
You’ll no longer have to tell stakeholders, “We made good progress. Trust us. But there’s nothing to show you this time.” Instead you’ll have split stories in ways that demonstrate meaningful progress.
thanks you RSS link