A valuable trick I sometimes forget: first solve the easy customer.
- Before we continue, I feel we need to pull some real cases in this set of muses about story splitting. It can’t be super-concrete, because a) confidentiality and b) too much detail hides the idea. Hopefully, this will help a little with figuring out analagous ways to split stories in your case.)
In a medical insurance environment, we manipulate a lot of claims data, sending out invoices, making reports from it all, and so on. We’ve found an intricate but real case where we can identify type X claims, process the hell out of them, and turn them into invoices. This will add a nice bullet no one else has: "supports type X claims, recouping an average of 8% more income".
The problem is that clients have over a dozen site-specific attributes that actually play into the claim X manipulation. That is, the combinatorics for the story are quite messy. All the clients, ultimately, can do it. That is, they all, ultimately, can be "claim X processing eligible". It’s just a matter of the size of the problem. If we just jump in and do the whole thing, you’re looking at six weeks of work before the "story" can ship. Ugh.
In the first hour of showing us the scheme, an analyst shows us how to take four very different clients and do it. Two of them are middling hard, one very hard, one almost straight-line code. We get better at seeing the differences, and in the second hour we do another ten.
Six weeks. No way. So how do we split it?
"Show us that dead simple one again."
We probe a little bit, and it turns out that the place we pulled the sample from always has only claim-X-processing-eligible claims.
(Tech note: it’s because they’re specialists. 100% external contractor that only does blood work. All but two of those combinatorics just disappear from the claim X manipulation.)
Answer: Solve that one lab’s claim X problem. That pulls us down to four days. We weren’t done splitting yet, but four days is one helluva lot better than six weeks.
From a code perspective, the story involves making a claim-X Strategy, with two flavors, No-Op and Crazy Eddie’s Bloodwork Warehouse. Every client defaults to the former except Crazy Eddie. (Why are his prices so low?)
Downside: we’re not going to be able to check off the bullet that says "handles claim X".
Upside: We got size, verticality, and shippability. We got a new feature for Crazy Eddie. We got much closer to handling anyone who does contracted outsider work.
The final split looked like 1) make the strategy with no-ops on both sides. 2) make crazy eddie side do the right thing in one of its four combinations. 3) make it do the right thing in the othe three. Each story was <1 day.
Now, looking over this example, I feel sure there’s something there to catch your eye: "this is obvious".
Mmmmmm. Yes. Splitting stories is one of those things where it is usually obvious, once you see it.
The trick is to take your time and look for the split. I called this out earlier in the series: if you don’t resist larger stories, you won’t get smaller ones. Most newcomers to the agile world don’t yet know when to resist. Once they start, though, they get quite good at it.
Have a lovely Monday. Split something. 🙂