According to a survey of over agile 2,000 practitioners by Mike Cohn, at Mountain Goat Software, one of the top three challenges faced in writing user stories was spending too much time trying to split stories in a meaningful way at the cost of building something.
And a survey specifically targeted at splitting stories identified these 4 key concerns:
- How to split stories so that they show value but can be delivered in an iteration
- How to avoid the temptation to split stories between functional areas (e.g. dev and test)
- How to spend the right amount of time splitting stories so you’re not doing it all the time at the cost of getting something built
- How to not get lost in the 50+ ways to split a story that are out there
Mike lays out a model for splitting that brings some simplicity, structure, and clarity to the topic. He suggests that internet sites that give 30, 50 or more different ways of splitting stories just create confusion, and that there simply aren’t that many different ways to look at the problem usefully. He boils it down to what he calls the SPIDR model:*
Spikes – You may need to break out some research. This one is actually the choice of last resort when using the others in the SPIDR model doesn’t seem to resolve the problem.
Path – If there are multiple possible alternative paths possible within the user story, maybe you can break them into separate stories (not necessarily one for every single path). For example, the thinnest happy path, the one option path, etc.
Interface – Maybe your first user story will be just for Android, etc.; maybe you’ll provide a very bland user interface with limited features
Data – Maybe in your first iteration on best vacation site, you’ll just pull in data about museums, then later data about historical tours in the area, then outdoor activities available, etc.
Rules – Maybe in the first pass, you qualify potential customers based only on credit rating, Might not be shippable, but you learn a lot. Then you qualify them according buying profession, then buying habits, etc. He also includes regulatory and non-functional constraints in this bucket.
Maybe this approach isn’t perfect but I’d say it’s a straightforward framework to follow that I think meets the 80/20 rule at the very least. Another model worth looking at is Richard Lawrence’s How to Split a User Story (www.richardlawrence.info)
I would say deep and mysterious is not Agile. If it starts to seem like user story splitting is a dark art, or one requiring multiple advanced degrees, take a step back. Try applying one of these straightforward frameworks and see how you do. Empower yourself and gain some confidence.
Hope this helps.
* Using SPIDR To Split Any Story, Mike Cohn (2017) https://www.betteruserstories.com/training/videos/2