Project Velocity

One of the most challenging and mysterious aspects of software development is predicting when software will actually be done. The inability to forecast releasable software causes havoc with the marketing and sales machinery of a business and leads to a lot of external grumbling about that "&%$(*@! software development group". XP has an innovative way to mostly resolve this chronic problem. It can be summed up as "yesterday's weather." If you were asked to forecast tomorrow's weather without access to professional forecasters or your own meteorological tools, the best piece of information you could have is today's weather. Without any other information, guessing that tomorrow will be like today will get you closer to the forecast, on average, than any other method. XP uses this metaphor to forecast product release dates. It can do so because XP constantly monitors "yesterday's weather" by measuring the velocity (how much work gets done) in an iteration. It uses this information (or more likely the average trend over several iterations) to forecast how much work will get done in the next one.

At this point you may be thinking, "That sounds pretty reasonable. What's so counterintuitive?" Here's the counterintuitive (and simplistically brilliant) part: The way velocity is measured in XP, it doesn't make any difference why velocity is what it is. It just is. Practically, this means that XP doesn't concern itself with whether developers are chronically optimistic or pessimistic in their estimates, whether they are fast or slow coders, or whether they create quality code in the first, second, or third attempt. That is a people management concern for the engineering manager. XP is concerned with accurate planning and to accomplish that it reduces all above variables, plus differences among individuals and pairs, into one simple number: project velocity. Think of all the time that will be saved by not trying to figure out who's to blame.