Yeah, FogBugz had a very similar feature 15 years ago.
It was a hybrid between the approach proposed in the article, and the "always multiply by N" technique.
Basically, FogBugz always asked you for your own best estimate. It tracked how much longer the actual time to completion was compared to your best estimate, and learned a simplified statistical distribution of your personal multipliers (e.g. in 80% of cases your estimate was 20% shorter than actual time to completion, in the remaining 20% of cases it was 10% longer).
FogBugz used the learned distribution to perform Monte Carlo simulations, and presented you with estimates of actual time to completion (e.g. "in 95% of simulations the project didn't take longer than 30 work days"). The great thing about this method is that it automatically accounts for chronic optimists, who always think it'll be ready to ship soon, and underestimate difficulty. The learned multipliers tell the algorithm that the estimates made by the optimist tend to be underestimates, so that it can present you with a "debiased" estimates.
E.g. if something always takes at least twice as long as Developer Anderson says it will, then FogBugz would tell you: "Anderson estimated 10 days, but based on past data I think it'll take at least 20, and it took less than 15 only in 5% of the simulations".
It had a very simple algorithm at its core, but the developers were knowledgable ,and had tons of data about project management. This allowed them to add many empirically verified "embellishments" (e.g. if the algorithm didn't have enough data about your specific multipliers, it assumed that your multipliers were about the average of your coworkers'), which made the algorithm surprisingly accurate in the end. Certainly better than any estimates most people could produce by hand.
I never tried FogBugz but I heard good things about it, similar to what you've written. It's surprising it didn't catch on more if it's that good? I mean, I suppose it could still catch on, the product still exists as far as I know.
I’ve written about why FogBugz failed before, but it basically came down to Atlassian having vastly better marketing, being much more willing to support every edge case instead of being opinionated, and having a better pricing model.
Unrelated, the new owners of Kiln and FogBugz are asshats, I moved my stuff off ages ago, and I’d encourage anyone else still on them to do the same.
It was a hybrid between the approach proposed in the article, and the "always multiply by N" technique.
Basically, FogBugz always asked you for your own best estimate. It tracked how much longer the actual time to completion was compared to your best estimate, and learned a simplified statistical distribution of your personal multipliers (e.g. in 80% of cases your estimate was 20% shorter than actual time to completion, in the remaining 20% of cases it was 10% longer).
FogBugz used the learned distribution to perform Monte Carlo simulations, and presented you with estimates of actual time to completion (e.g. "in 95% of simulations the project didn't take longer than 30 work days"). The great thing about this method is that it automatically accounts for chronic optimists, who always think it'll be ready to ship soon, and underestimate difficulty. The learned multipliers tell the algorithm that the estimates made by the optimist tend to be underestimates, so that it can present you with a "debiased" estimates.
E.g. if something always takes at least twice as long as Developer Anderson says it will, then FogBugz would tell you: "Anderson estimated 10 days, but based on past data I think it'll take at least 20, and it took less than 15 only in 5% of the simulations".
It had a very simple algorithm at its core, but the developers were knowledgable ,and had tons of data about project management. This allowed them to add many empirically verified "embellishments" (e.g. if the algorithm didn't have enough data about your specific multipliers, it assumed that your multipliers were about the average of your coworkers'), which made the algorithm surprisingly accurate in the end. Certainly better than any estimates most people could produce by hand.