During my career in Software, the problem of estimating the time, effort and cost of a software project has been one of the hardest.
Agile estimation
When I learned about Scrum, I was totally convinced that estimation was legit. It bothered me that when estimating using Fibonacci numbers, people would try to do arithmetic with them like it meant something. It doesn't. Calculating velocity was more or less pointless.
I still buy that relative estimation was better than absolute estimation, however, in order to get good at estimating, you have to have seen many similar items. In my career, I have been switching technologies and industries every couple of years so pretty much every task is, in some sense, different and it's hard to compare with the past.
The time discussing whether something is an X, XL or XXL was almost too much for me. I wanted to get started building something small, then extend it a bit, then a bit more, you know, iterative and incremental progress instead of trying to nail down an accurate estimate the first time.
Today I am convinced that estimation in this way is a complete waste of time.
Forecasts
While looking for alternatives I found the #NoEstimates video from Allen Holub and I was hooked. The idea of using past performance to make projections about the future was already present in Scrum and I was more or less comfortable taking it for granted. Calculating velocity never really made much sense to me, given what I said about doing arithmetic with Fibonacci numbers, can you imagine doing it with T-Shirt sizes?
Holub proposes instead to do away with all the time used for trying to estimate a task and instead ensure that tasks are as small and that they are prioritised. Nobody wants to spend time doing stuff that does not matter.
Measuring actual time it takes to complete enables you to stop using guesstimates, it's faster and easier to do. Making tasks small means there are more data points (measurements) available to create a forecast/projection of how long it may take to complete a list of tasks.
Priorities
With agile estimation, you don't know when a particular item in the backlog will be completed. This gets more difficult as more stories are dropped in order to make the deadline.
A forecast will tell you the likelihood of completing a specific task at a given time and it can be recalculated as you rearrange items in the backlog.
The ease and speed of calculating a forecast can be a stronger motivator for decision makers to try and rearrange the backlog with confidence in order to visualise different scenarios. This is harder to do with agile estimation methods since it's difficult to anticipate the impact that rearranging the backlog will have on the completion date of a task.
Challenges
Measurements + forecasting seem to me like they should yield better results when used for project estimation. However, it's difficult to apply. Even if you manage to master all the concepts of how to properly use a forecasting technique, you still need to provide your estimate of the project's cost and effort and duration before you can get the money to start the project.
Another difficulty is that once a project is started, it's difficult to gain mind share about using a forecast instead of estimates. People are already struggling to make sense of Agile estimation methods given all of their obvious pitfalls. Convincing them to use something like a Monte-Carlo simulation to forecast the likelihood of a task being done at a particular point in time can be challenging at best.
Further reading
- #NoEstimates, an introduction @ Allen Holub' Blog
- No estimates by Vasco Duarte @ YouTube: how you can predict the release date of your project without estimating