Story Splitting
optionality is everything
If Agile is about anything, it’s about preserving options. Incremental progress is what we do, but what we purposely refrain from doing goes a long way toward safeguarding our ability to make choices in the future. When splitting software stories, our chances of fostering successful outcomes are improved to the extent that we keep our options open!
A commitment to delivering at the end of an iteration, implies a commitment to the elimination of certain options. What we don’t commit to is our inventory of unexercised options.
Commitment is a loaded term, because we are more familiar with the term in a social context such as in an intimate relationship where an unwillingness to make a commitment has strong moral overtones. The unwillingness to close off other opportunities in a budding relationship makes a determined outcome of happily ever after somewhat unlikely. In this context, keeping one’s options open is more along the lines of unfinished business. Good luck with that.
In contrast, for many of life’s decisions, we don’t need to commit to some specific pre-determined outcome so much as we just need some favorable outcome: most any scenario that leads to a winning hand will suffice. In this context, the concept of commitment is just the tipping point of probabilistic outcomes, where a winning strategy starts with knowing when to keep one’s options open.
The sense of the term we’re interested in here is more along the lines of what we find in poker, where reluctance to commit is expressed by checking. The alternative acts of raising or calling all invoke a greater commitment. Folding is also commitment, where the declaration extinguishes all the the possible outcomes that existed in the moment before the act; the probable and the unlikely alike.
In poker, there is no happily ever after, just a series of winning and losing hands; no one will be offended by your lack of commitment to any particular hand, and no one will celebrate your moral fortitude because of your commitment to a loosing strategy. If you do end up top dog, people will recount the sage raises and calls you made, but will likely not have noticed the actions that you choose not to take, the intentional inaction that kept your options open.
Staying Open to Opportunities
The essence of commitment is the closing off of other opportunities. That is precisely what makes it powerful in the context of personal relationships, whereas in poker it is staying open to the right opportunities that is the crux of a winning strategy.
An option is what … allows you to benefit from the positive side of uncertainty, without a corresponding serious harm from the negative side.
— Nassim Taleb
Thinking of software stories as a series of poker hands will be helpful in understanding the critical importance of preserving optionality. You’re not going to win every hand. The important thing is to have a strategy where you end up with more winning hands than losing. The key to a winning strategy is learning what to base your commitments on, to stay open to the right opportunities.
Negotiability
INVEST is a popular mnemonic device for recalling key qualities for software story splitting. The technique is to ask yourself if a given story evaluates as true for each of these six attributes:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
The quality we’re interested in for the context of this discussion is Negotiable, because it is a proxy measure of optionality.
Testing the negotiability of a software story is intended to dry out over-specification, where requirements or acceptance criteria unnecessarily imply some specific solution. The sub-optimum nature of a particular solution adopted early is easily overlooked; once there is investment in the solution, then resistance to changing direction increases, even when a more optimal solution becomes evident.
Story Splitting for Capacity Planning as Anti-Pattern
A common anti-pattern is to encourage story splitting in Sprint Planning for the purpose of trying make sure it can get done within the Sprint. This practice is one of a bundle of Capacity Planning anti-patterns (which in any event don’t contribute much to either capacity or planning).
Early story splitting burns options. The options are opportunities that the development team exercise in making decisions about how to tackle the work within an arbitrary timeframe.
By choosing to work in Sprints, we’ve already burned the option to take a little longer if that’s what the work requires; it’s a tradeoff we accept for the theoretical benefit of realizing a cadence. If, for the purpose of trying to make it fit in the time-box, we also take away scope, we further reduce the choices available the development team to find the most favorable outcome.
Closing Off Opportunities Without Regard to Merit
Premature story splitting results in a reduction in the range of possible avenues. Consider that every line of code written becomes a sort of commitment, not because it can’t be undone, but because so long as it exists, it becomes a placeholder blocking alternative possibilities. For good decisions, this is exactly what we want. What we want to avoid is closing off opportunities for arbitrary reasons.
Do not confuse good reasons for deciding how to do splits from arbitrary ones. Arbitrary reasons just means anything that doesn’t derive from the story itself. The INVEST attributes are valid reasons for splitting stories. For example, stories that represent multiple Independent areas of work should be split based on the principle of Independence, and so on. In contrast, capacity planning is an arbitrary criteria which is usually accommodated by stealing from the principle of Negotiability.
Negotiability Depends on Optionality
A software story’s negotiability is a factor of the options implied by the specification. When sensible principles of story decomposition are respected, and a resulting story requires more effort than can be realized in the span of an iteration, that additional scope is just free optionality: it costs us nothing to defer the split to the end of an iteration. “Small” is already a criteria of decomposition. We’re not talking about work that we’d expect to drag on for months, just longer than might fit neatly in a single iteration.
When we defer this kind of size splitting of stories to the end of the iteration, then we have an increment of work delivered against the story to evaluate. At that point, how to split is straightforward: the delivered work defines one side of the split and the remaining specification that is rolled over becomes the other side of the split. The development team made the split decision when they chose what part of the specification to implement.
You might be thinking that this is a very long explanation for what is effectively just an argument for rolling over work into the next Sprint, but that would be missing a couple important points: first, that rolling over work is no substitute for making a serious effort at getting decomposition right; something that is really hard work and one of the more challenging exercises that teams face; and second, that preserving optionality is a central guiding tenent of feature and story decomposition practice.
Getting decomposition right while preserving optionality is the foundation on which software is built.
Premature splitting of software stories for the purposes of capacity planning is like a poker player who folds on every third hand as a strategy to make their cash last longer. If burning your options seems more attractive than playing the cards you’re dealt, the odds are stacked against you.
Michał Parzuchowski — "Poker Hand"
Marin Tulard — "Burning Lottery Ticket"
Alperen Yazgı — "Bag of Dice"
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.