Limited Investment With Timeboxing
It’s a common misconception that Scrum sprints, and timeboxing more generally, are ways to set tight deadlines. This misconception is so common that Boehm1 Balancing Agility and Discipline: A Guide for the Perplexed; Boehm & Turner; Addison–Wesley; 2003. actively discourages people from timeboxing: tight deadlines create pressure, which leads to lower quality and time wasted inventing excuses and pointing fingers.
That’s a shame, because timeboxing – properly done – is such a useful risk reduction technique.
Timeboxing reduces risk by limiting how much time (hence money) we commit to something, so we can double down on winners and stop investing in losers. The goal of a timeboxed effort is not to complete something but rather to evaluate feasibility and profitability. By the end of a timeboxed effort, we should not count on having a deliverable, but we should have more material for the decision on whether to continue spending time on it.
Plan sprints based on potential
This has consequences for how we select tasks for a Scrum sprint. The question is not
How much can we definitely complete in the next two weeks?
Rather, we should ask,
Which of these things are promising enough that we are willing to dump the next two weeks into them, even if there’s no guarantee of ever getting anything out of it?
In other words, we’re looking for the things that have so much potential revenue2 Either because a small-ish amount of revenue is near guaranteed, or because there’s a low probability of an unworldly amount of revenue. that it’s worth betting a couple of weeks on them, on the chance that the revenue does materialise. This is exploiting risk to our advantage. We focus on the high upsides and make sure to limit our downsides – not only is that a sensible insurance policy against mistaken decisions, it’s also how to thrive in the event of black swans.
Everything is a spike
You may sense some overlap between this idea of timeboxing and an extreme programming spike. I don’t think there’s a meaningful difference between the two. I think if we’re not treating every user story as a spike-light we’re leaving money on the table by accidentally focusing on the wrong things very often. Product development is a process of discovering and creating usable knowledge. Treating everything as an experiment creates more knowledge than assuming things are as we think they ought to be.