Hey, it’s Richard again…
In 2007, when I wrote the original “Patterns for Splitting User Stories” article, I ended with a challenge: “Bring me your unsplittable software stories.”
Over the years, there have been many seemingly unsplittable stories. They’ve followed 3 themes:
- We just don’t know how to split this sort of thing yet
- It’s really not worth splitting into user stories
- It’s not a story or feature to begin with
Here’s how to handle each one…
For number 1, I coach people through the splitting patterns, and an hour or two later, they’re able to split this sort of thing in the future. It wasn’t an unsplittable story. It was a story they didn’t know how to split yet.
Number 2 is less common, but it happens. User stories are a tool for organizing work around customer complexity. If we don’t know what people want, what will solve their problem, organizing the work around incrementally solving the problem in user-visible ways is a great way to maximize value and reduce risk.
But occasionally, there’s a piece of work that either has mostly technical complexity or is solidly complicated. An example of the latter I encountered once: We need to port our network driver to run on updated hardware.
The behavior didn’t need to change. The updates were well documented. The definition of success was clear. And there was no value in delivering incrementally (in this case, it wasn’t even possible to ship with half a network driver).
So, the right move here was to treat this as a mini project. Decompose the tasks and make a plan. Identify milestones to demonstrate progress. Track and manage the work to stay on top of delivery risk.
Like I said, this is pretty rare in software. Users are our biggest source of complexity.
Theme #3 is the one I see the most in my coaching. The majority of the time, if someone brings me their “unsplittable story,” it’s not a story or feature to begin with. It’s a component or a technical task. Perhaps it’s masquerading as a story (”As a developer, I want the database to support multiple addresses per customer, so that we can build features around multiple addresses.”—please stop doing this, btw). But it’s not a change in system behavior described from the perspective of a user of that system.
So, what do you do when you or your client wants to split one of those into good user stories?
Step 1 on the story splitting flowchart, “prepare the input story,” is really about making sure you actually have an increment of value to start with, a feature or user story. And if you don’t, if it’s a task or component, then you’ll need to combine that with the other tasks or components that together become an increment of value.
In other words, you have to find the feature the task or component came from. Then, you can split it differently.
You often have to go big before you go small.
Once you’ve found the larger feature, now you can proceed through the flowchart, applying the story splitting patterns and testing the results.
The key move here is realizing that “unsplittable stories” are often the result of splitting a feature or story into tasks or components and undoing that so you can start over.
Do you help other people learn to split features and stories? Coaching story splitting is more challenging than doing it yourself. But there are common challenges you can be prepared for and useful tricks you can have in your toolbox.
On April 25, join me for a live workshop on story splitting for coaches. I’ll share what I’ve learned in almost 17 years of coaching story splitting so you can help your clients succeed with this essential Agile skill.
Last updated