You’re Splitting Your Stories Wrong!
Who hasn’t heard that phrase? I wager everyone ever to write stories has been told by someone, they’re doing it wrong.
In my line of work I see Backlogs for many different products, maintained by many different people, employing many different styles. And it’s been eye-opening.
I’d like to share some observations with you. Some concerning best practices, some concerning commonly seen mistakes. And I don’t want to just preach to you, I’d like to make you think about why something is a good or bad practice, understand the consequences of your choices in the matter, and be ready to adapt your workflow to your unique context.
To start this series off, let’s talk about…
Splitting User Stories.
There are generally two ways one can split a story: Functional, and Iterative.
Functional splitting is when you separate a sequence of functions that together form the value of your story.
Iterative splitting is when you form increments that each deliver on the value proposition of your story, with increasing fidelity.
So how do we know when to use which?
Enter “Closed Loops”.
When we split stories, we always run the risk of producing new stories that do not comply with the holy grail, the INVEST-standard of being independent, negotiable, valuable, estimable, small, and testable.
This is due to the tendency, and good practice, to talk about entire solutions, rather than individual stories. Doing so allows for a big picture communication, helps designers, developers, and testers alike to understand the context of individual stories — but it also distracts from the individual value of each individual story.
Within a solution, there may exist loops, such loops each represent the fulfillment of a given intent. That is, they have a start, and an end. Exactly one each. Each one of these loops represent a unique value that is delivered through them. Some of them may branch off of others.
By identifying these loops, one can identify candidates for individual stories, using functional splitting. Each story delivers a distinct value. All be it they may have dependencies between them — that’s OK as long as those dependencies are not circular.
Sometimes the resulting stories from functional splitting are still too big, or too expensive, so what do we do then?
We look at each of the loops and contemplate how we could make the loop smaller. Not necessarily as a final solution, but as an iteration of the entire loop. In essence “Can we close this loop for less?”. You should ask this question all the time, it saves time, money, and headache.
Beware! A loop must remain closed at all times. This can quickly become a pitfall and generate risk, degrade your product consistency, and prevent you from outputting a PSP at the end of your iteration cycle.
Sweet Temptations
The greatest threat to keeping loops closed is the tendency of engineers to keep applying functional splitting heuristics to loops. Because even though the loops represent an undivisible unit of value, and implementing only part of them creates no, or negative, value, to an engineer this may not be so obvious. Sure, you could implement this function, then that one, and you can develop them independently. That’s true. It’s just not desirable from a product perspective.
Implement the backend function in a first story, then put a partial implementation of the frontend in another story, then tie them together in yet another story? Unacceptable. Not because we’re purists and pedants, but because it does not generate a visible increment on the surface of the product. Because the loop is not yet closed. At worst, it may even introduce broken loops, getting the user stuck, or wondering whatever this function even is supposed to do.
Oh, but what if the lesser iteration of a loop does not satisfy stakeholders? What if we get bad feedback when we implement a lesser version of something? — We take the feedback. That’s what we do. We want feedback, there is no ‘bad’ feedback. It’s just another chance to learn something about the value proposition’s validity for the loop we implemented.
By embracing the iterative nature of product development, by releasing often, measuring often, and improving often, do we inch closer to the product we ought to build, rather than to the product we set out to build.
But Does This Not Generate Waste?
Don’t we implement the same thing multiple times by adding iterations in between that we already know we want to replace? — Yes.
And that’s the price we pay for always having a potentially shipable product, an actual product increment, at the end of an iteration cycle.
And you never know, the feature you just implemented in its most basic version, might just turn out to be a complete flop, and you’ll be grateful you didn’t invest more into making it fancier. That’s also part of being agile: to test, validate, and throw away.
And with these thoughts, I leave you, dear reader, to draw your own conclusions, to find out for yourself whether, or where, to implement what you have learned from this read.
Until next time!
