I came out of the article with the same question. I was almost jumping up from my desk with excitement through the first 3/4 of the article, but then the conclusion felt a bit lacking when it never directly addressed the estimation problem...

You don’t. You focus on efficiency and throughput.

Complexity and high variability of estimates is the real problem. You can address that some by training developers on how to estimate, which I’ve heard called calibration, and then spend a lot more time digging in up front on those estimates.

Long term, a ball park can give a good idea but most aren’t going to be more accurate until we dig in. If you are choosing between projects based on expected ROI then diving in ahead of schedule to get a clearer picture makes sense.

If you are delivering a specific product no matter what, then you optimize for throughput.

It’s more valuable to tune the engine so you can drive 70mph than to slow down to 20mph with the goal of accurately predicting your speed.

>If you are choosing between projects based on expected ROI then diving in ahead of schedule to get a clearer picture makes sense.

>If you are delivering a specific product no matter what, then you optimize for throughput.

I really like this, thanks for the response!

While I agree it is more valuable to optimize for speed for each person speeding there is a traffic cop worried more about what the sign says than the final result. Sure a company might want to go as fast as possible because it makes them lots of money but the accounting people now can't write budgets very easily so they push for more accurate estimates.