[draft] Estimations and timelines

The way we estimate software projects is flawed. We sit down every quarter, in groups of people that may or may not know the project best, and we try to estimate how long it will take. We then put the number of days in a tool, leave out any other estimation metadata, and then expect reality to match that initial guess. We get frustrated when it doesn't, put pressure on the team to move faster, or reduce the project scope. And all this because that one number that we've ended up with doesn't match the reality.

But the reality is much more complex than that. When we estimate a large project, we try to split it into multiple pieces, we estimate those pieces individually or split them further, and then add up the estimations to get the final number for the large pie. But with every split, we assume that we didn't leave out any piece of the puzzle, and this assumption accumulates to the final estimation error.

While it is impossible to estimate perfectly, as we can't predict the future, I think we can do better than just coming up with one number at the beginning of the project.

Update the estimates

Estimate more often, and create the expectations that the initial estimation can change. It was just an estimation, after all. Once the team learns more about the world, and the initial estimation disconnects from reality, the team should be encouraged to communicate that. The sooner, the better.

Multiple perspectives

Involve multiple people in the estimation, and combine their estimations. Not only do the different perspectives and skills cover a wider area of the knowledge required, but the individual estimation errors can cancel each other.

Don't use just a single number

Don't use a single number as the result of the estimation. There are many nuances in estimating how much time something will take, and valuable knowledge is lost if all we take is the final number.

• Keep the confidence of the estimation. 2 estimated days of work on something you've done 100 times before is different from 2 estimated days of work on something new.
• Maybe use an interval instead of a single number. Sometimes it's easier and more reasonable to say something can take between 2 weeks and 3 weeks, rather than saying just one number. And it may be that you know 2 weeks is more likely than 3 weeks, so a probability distribution over the interval would make even more sense.
• Keep track of the assumptions that the estimation is based on, so it's easy to track when these assumptions change, and how that impacts the estimation.

A part of the problem is that the tools we use for planning the work are limited to only one number as the estimation, and don't nudge us in keeping it updated.