The Art of Agile Development, 2nd Edition

Forecasting

AUDIENCE

Product Managers

We can predict when we’ll release.

“When will you be done?” Programmers dread this question. Software development has so many details, it’s impossible to know exactly what’s left to be done, let alone how long it will take. Yet stakeholders have a genuine need to know how long the work will take. They need to plan budgets and coordinate with third parties. To create trust and show accountability, you need to be able to predict when you’ll release.

Making these predictions is usually called estimating, but that’s a misnomer. Estimating is just one technique for making predictions, and not even the most important one. The real secret to predicting well is to understand uncertainty and risk. That’s why I call it forecasting instead.

Uncertainty and Risk

At first glance, Agile offers the perfect solution to forecasting: if you’re using iterations, add up your stories (or their estimates), divide by your capacity, and voila! The number of iterations left before you’re done. After all, capacity and slack give you the ability to consistently make and meet iteration commitments. Shouldn’t that mean you can make reliable release commitments, too?

Unfortunately not. Imagine you’re on a team with 30 stories to finish before release. Your team consistently finishes six stories every week, so it will take five weeks, right? It’s January 1st, so you tell your business stakeholders you’ll release five weeks later, on February 5th. They’re enthusiastic ...