This is the first article in a series that will introduce alternative ways to forecast date, cost and staff needs for software projects. It is not a religious journey; we plan to discuss estimation and forecasting like adults and understand how and when different techniques are appropriate given context.
Stakeholders often ask engineers to estimate the work for a project or feature. Engineers then arrive at a number of story points or a date and present the result as a single number. They rarely share uncertainty or risk with those estimates. Stakeholders, happy to get “one number”, then characterize engineer estimates as commitments, and make confident plans that depend on achieving the estimate. Problems arise when uncertainty and risks start unfolding and dates shift. Failure to communicate engineering uncertainty is a key difference between estimation and forecasting.
In our series, we will discuss how probabilistic forecasting can be applied to IT projects. We will show how to quantify certainty when presenting important date, cost and staff estimates, and thus create a forecast. For the purposes of this series, a forecast differs from an estimate in the following way: Forecast values are presented with their assessed probability, and never alone.
As weather forecasts always puts a percentage likelihood of rain in your area, engineering forecasts will always add a percent likelihood to any date, cost or staffing estimate.
In part 2, we will look at how weather forecasts compute the probability of rainfall, and how we can do the same for IT projects. Agile methods provide great data that can help quantify the probability of meeting date, cost or staffing estimates.