Roll a Dice to Estimate

Estimations are hard and engineers are lousy at it
Published on 2024/02/14

It is not mystery that estimating is difficult. Needless to say larger projects are increasingly difficult to estimate and you could work a whole month trying to break it down to tasks small enough that you are confident in how much effort is required to complete each one. We are currently in the process of wrapping up a year long project, a massive refactoring that brought a wide spectrum of improvements. If the project was mostly net-new work I believe estimating could have been "simpler" but in this specific case it was almost impossible being able to cover every edge case without spending weeks and weeks just researching. But today I wasn't really thinking about the hard nature of this specific project but about estimations.

It is common in engineering companies to account for how good ICs are at estimating work. This is especially useful for planning and to understand how many people should be assigned to a project if we have specific deadlines or just for organizational purposes. This is important if identified earlier on and not when it's too late. As mentioned in "The Mythical Man Month" adding people to a late project is just going to make it later (onboarding ang all).

For this reason, and many other, I push my team to provide a reasonably informed estimate, but I don't expect the delivery to be within days of the original estimates. Projects evolve over time and the longer you work on a project the higher the chances things change. Where I see people standing out, is the ability to keep stakeholders informed and up to date with the latest estimates. I usually invite project leads to take some time every few weeks to check if the estimates are still valid or if more information has surfaced to update them. Generally speaking we (as an industry) are pretty lousy at estimates.

Thoughts

What I look for in good ICs, is (among many other characteristics) the ability to keep up with estimates. Medium to large projects are difficult to estimate accurately but the goal is not to have an incredibly precise delivery date (they are called "estimates" after all). When assessing the performance of an individual I don't find it fair to ding them for not excelling at estimates and I was happy to find out that many other managers feel the same.

But how do you guarantee delivery with hard commitments? In an ideal world I prefer to have delivery ready the quarter before the hard date and I tend to allocate people accordingly. We experienced something similar with my team a while ago and decided to go about this much differently moving forward. All it took was one experience and from then on, scheduling for a quarter ahead has proven to be a really safe bet to give us room for ample testing, qa-ing, and all the unknowns.

0
← Go Back