5/8 - User Story splitting
5/8 - User Story splitting
Splitting consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.
Hello Product Managers, This week’s newsletter is brought to you by UserLeap
UserLeap enables product teams to quickly and easily understand their audience, improve their product, build their roadmap, and solve complex business problems through a combination of contextual micro surveys, AI-based text analysis, and 75+ research templates. Learn more!
User Story Splitting
The goal of story writing is to describe and create increments of user value that can be implemented by a development team in a short amount of time, typically on the order of hours or, at most, a few days.
Before a user story is ready to be scheduled for implementation in an upcoming iteration, it should be “small enough,” the usual rule of thumb being “a story that can be completed within the iteration”.
However, many user stories start out larger than that.
“Splitting” consists of breaking up one user story into smaller ones, while preserving the property that each user story separately has measurable business value.
Splitting stories lets us separate the parts that are of high value from those of low value, so we can spend our time on the valuable parts of a feature. (Occasionally, we have to go the other way as well, combining stories so they become big enough to be interesting.)
There’s usually a lot of value in getting a minimal, end-to-end solution present, then filling in the rest of the solution. These “splits” are intended to help you do that.
Why Story Splitting Matters
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 and features into good, small stories.
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.
Fortunately, story splitting is a skill that can be learned in a relatively short time. We’ve seen teams go from struggling to fluently splitting stories with just a couple hours of practice and some simple tools.
What Makes a Good User Story?
Before we can talk about splitting user stories, we need to make sure we have a shared understanding of what a good story is and what sorts of things can and can’t be split into good stories.
A user story is simply a description of a change in system behavior from the perspective of a user. It describes something a user wants to do with the system or wants the system to do for them that it doesn’t do today.
User stories are great for translating that customer empathy into a series of changes to a software system while maintaining the user’s perspective throughout.
The goal of story writing is to describe and create increments of user value that can be implemented by a development team in a short amount of time, typically on the order of hours or, at most, a few days.
This allows the product owner and the team to get quick feedback on the larger feature being built, with the expectation that this will steer the ultimate direction of the feature and maximize user value.
Story-splitting techniques
There are many techniques for splitting stories. Here are some of the more useful ones.
Split by capabilities offered This is the most obvious way to split a large feature. Look at the different capabilities being offered and split each one into its own story. For example, the capabilities “sort and search” may each be its own story. Splitting further, each way of sorting or searching may be its own story.
Split by user roles Administrators interacts with a system differently from normal users. Teachers interact with instructional software differently from students. By defining the different roles in your system, you can split features and stories to address the unique needs of each role.
Split by user personas Even in the same role, different people interact with software in different ways. A power user wants lots of keyboard shortcuts. A casual user may want a lot of intuitive, hold-your-hand forms of help. Handicapped users may need very different ways of interacting with the system, even though they are doing the same tasks as other users.
Split by target device You can’t assume that users are interacting with your system using a standard computer. Various smartphones and IoT devices need to be considered in your stories. Splitting stories by device provides a more natural experience for your users.
Cynefin and Story Splitting
Dave Snowden’s Cynefin model is a helpful way to think about the right strategy for a problem depending on its complexity. We find Cynefin so useful, we include it in almost all our workshops, either as prerequisite content or in the workshop itself. If you’re not yet familiar with the model, check out our overview.
Story splitting looks different for each Cynefin domain. Here’s how:
Obvious – Just build it. Or, if it’s too big, find all the stories, and do the most valuable ones first.
Complicated – Find all the stories, and do the most valuable and/or most risky ones first.
Complex – Don’t try to find all the stories. Find one or two that will provide some value and teach you something about the problem and solution, build those and use what you learn to find the rest.
Chaotic – Put out the fire; splitting stories probably isn’t important right now.
Disordered – Figure out which domain you’re in before splitting so you don’t take the wrong approach.
The most important nuance is in the complex domain, where starting the work will teach you about the work. In this situation, it doesn’t make sense to try to find all the small stories that add up to the original, big one. Instead, it’s more productive to find one or two you can start right away in order to learn.
Some are uncomfortable with this approach, wanting all the stories enumerated and sized to be able to project time over the backlog. But if you’re really in the complex domain, this only gives you the illusion of predictability—the actual stories are likely to change as you get into the work. Better to be transparent about the uncertainty inherent in complex work.
Vertical vs Horizontal Slices
You’ll often hear the term vertical slice in reference to good stories. This is about the shape of good stories relative to software architecture.
A vertical slice is a shorthand for “a work item that delivers a valuable change in system behavior such that you’ll probably have to touch multiple architectural layers to implement the change.” When you call the slice “done,” the system is observably more valuable to a user.
This is in contrast with a horizontal slice, which refers to a work item representing changes to one component or architectural layer that will need to be combined with changes to other components or layers to have observable value to users.
Let’s look at a really simple architecture. There’s a UI layer, some business logic, and a database. Your system may be more complicated than this, but it probably contains at least these three layers.
To get most of the INVEST attributes, a story is necessarily going to touch all 3 architectural layers. We probably won’t be able to deliver value without some UI changes, some logic changes, and some persistence changes. Thus, a story is a vertical slice through the system.
Sometimes those vertical slices are pretty wide. When we get into story splitting, we’ll talk about how you find thin vertical slices inside those wide ones, but for now it’s enough to know that stories should cut across architectural layers as necessary to deliver value.
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.
When teams work in vertical slices, they
Make value explicit in their backlog
Have more conversations about the value
Tend not to accidentally build low-value changes
Get value sooner
Get earlier, higher-quality feedback
See constraints and inventory more easily and can respond accordingly
Become more predictable in delivering value (because working software becomes the primary measure of progress)
We could go on, but that gives you the idea. When we sat down together and mapped out the various habits we see in successful agile teams and how they relate to each other, we found working in vertical slices enabling or at least related to virtually every other habit.
Take a look at the stories in your product backlog, some you’ve recently completed and some in the future. Evaluate each of them against the INVEST criteria. See if you can find stories that are vertical slices and stories that aren’t. Then, see if you can improve your stories.
You might also like :
User Stories Playbook (Pre-Order @50% off)
User Stories and backlog management guide
User Stories and Backlog Management Playbook
Module 1 – Agile Manifesto and Principles
Module 2 – Agile Methodology
Module 3 – User Stories
Module 4 – Epic, Theme and Story evolution
Module 5 – Agile User Stores
Module 6 – The 3-C’s of User Stories
Module 7 – INVEST Criteria for User Stories
Module 8 – User Story Estimation Methods
Module 9 – Exercises and Case Study
This is for you if:
You are a new product manager
You don't know how or where to start
You've started working on the product role but still feel lost about writing stories
You're none of the above but you know someone who is. Gift them!
Thank you for your support, Product Mindset Team.