Back in the Old Days, project managers seemed to be obsessed with comparing time-based task estimates with the actual completion times of those tasks. When estimated and actual times didn’t align, we were advised to get better at estimating. The goal wasn’t really to learn to create perfect estimates. The goal was to achieve some level of predictability in an inherently unpredictable process for purposes of short-term planning.
Nowadays we know that the fine-grained estimates we might use to inform our short-term planning in the course of a project are not “the product” for which our customer is paying, and therefore are a form of “waste.” We’ve looked for (and found) alternatives to time-based estimation that can provide the information we need to plan our work without the overhead of preparing time-based estimates for individual tasks.
At two different clients this year, I’ve seen people comparing “estimates” (actually, relative story sizes) with the actual completion times of user stories, but not for the purpose of short-term planning.
It will come as no surprise to practitioners of lightweight methods that variation in cycle time varies in direct proportion to relative user story size. This seems only natural, as we tend to perceive a story as “larger” when there is uncertainty about it – either end uncertainty (what to build) or means uncertainty (how to build it); and the cycle times for those stories tend to vary more than those for straightforward, predictable stories.
The typical pattern is that relatively small stories (say sized at 3 points) exhibit little variation in cycle time, while larger stories (say sized at 13 points) exhibit greater variation. The greater variation reflects greater uncertainty about the large stories. Some prove to be much smaller than we feared, while others are much larger than we hoped.
If the relationship between story size and variability in cycle times is obvious, then what’s the value in tracking it? It turns out that the relationship is not obvious to everyone. Teams that are new to lightweight methods often do not perceive the importance of crafting stories that are more-or-less uniform in size. They also tend to leave uncertainties unaddressed during short-term planning, inviting surprises late in the development process (not in a controlled way, such as using experiments or spikes to validate assumptions, but in an uncontrolled way, such as hoping nothing bad will happen).
By making variation in cycle times visible to the team, we can underscore the relationship between large stories and cycle time variability. We can then use the information to support our recommendations for making stories smaller and more uniform in size, and for being sure we have a clear definition of “done” and a consensus about each story before we deem it ready to play. The payoff is not only that cycle times start to fall within a smaller range, improving predictability, but that they become generally shorter, as well, improving lead time.
I mentioned that I’ve seen this used at two clients. One is a very advanced “agile” shop and the other is just dipping its corporate toe into “agile” waters. In the first case, the metric is being used to help teams understand that they are ready to dispense with story sizing and move to a smoother continuous flow process model. In the second case, the same metric is being used to help teams understand the value of sizing stories consistently and keeping them small.
I wish I had thought of it!