Let History Be Your Guide

I was asked an interesting question yesterday, thanks to the magic of Instant Messaging. One of my friends at the company that I used to work for (in my capacity as AgileMan) wondered if either my wife or I had ever heard of something called "empirical forecasting." We hadn't, but as he told me more about what he'd been reading (and even shared some of it with me), I realized that it was something that I'd been practicing during the final few months of my employment. It's also a topic that I wrote about briefly in More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), although you'll just have to take my word for that until the book actually comes out! I just hadn't had a fancy name for it, until now!

Basically, that style of forecasting or planning involves using the empirical (or observed) data that you have, and only predicting what can be extrapolated from it. In other words, you only expect to get results that match what you've gotten in the past. That may sound obvious to some, but in my former company, it was rarely the way planning occurred. I sat in countless meetings in which statements like the following would be made:

"Our owners need ______ (some set of features) by ______ (some date in the future) so now we need to figure out how to deliver it."

Put another way, we'd start at a desired outcome and try to work our way backwards from it. I completely understand why we always felt that it was necessary to do things that way, but repeated failures of that approach should have incontrovertibly shown the folly of it at some point. Instead, it continued to happen.

What works much better, I believe, is to base your schedules on what has been proven in the past. For example, our development teams each had a certain average velocity (in Story Points) that they'd worked at for the past N Iterations (where N could reasonably be any integer between 3 and 6, let's say). Realistically, if that's what they did in the past, it's likely going to be close to what they'll do in the future. Therefore, you should expect about the same productivity going forward, and anything beyond that is just wishful thinking. If a team has 100 Story Points of work left, for example, and they work at an average velocity of 15 Story Points each Iteration, then you could reasonably assume they'd finish all of the features in roughly 7 more Iterations, with the caveat that the "remaining work" doesn't change dramatically in the meantime. What would happen all too often in my former workplace were frantic meetings in which endless discussion would ensue as to how to shorten that timeframe down to 3 or 4 Iterations. In the end, of course, it would still take 7 Iterations, or even possibly longer, if enough churn had happened in the process such that it actually made additional work for those involved!

In my conversation yesterday, the other person even talked about using simple line graphs to predict when the work remaining would hit zero, including accounting for features that have been added or removed. I think that sort of graphical representation can certainly help in such matters, as some people relate better to pictures than to words. In either case, though, your expectations are limited to an extrapolation of what's already happened, rather than relying on the time-honoured "... and then a miracle occurs" (as we all used to fall back on for those impossibly-hard university math exam proofs!).

In order to use this sort of technique, of course, you need development teams that can become fairly good at providing relative estimates (such as Story Points). That's no easy challenge, but it's also a big enough topic to warrant a separate blog post, and so I won't tackle it here!