same experience level, similar formula. Take your gut estimate, double it, double that new value, then add another "increment".

e.g. say you think it will take a day, so 2 days, 4 days, add another day, likely estimate is 5 days.

My pet theory is that when we estimate, we typically think of how long it will take to figure out a working solution to the problem, but forget about how long it takes to debug it, add tests, rework for changed requirements and unexpected nuances, and then roll it out and do any training, etc.

Great anecdote posted here a few years ago: https://www.quora.com/Why-are-software-development-task-esti...

Great read!! :D

This, the famous "prediction* Pi" rule seems to be correct also in my experience.

I make the most optimistic prediction and then * PI.

I use a similar methodology.

The part you didn't mention is that for most businesses it's better to be over than under in the estimation. I also explain this thought process to the various stake holders. We can certainly try to tighten up an estimate, but that runs a higher risk of being under which is usually a worse outcome (promised launch dates are missed, marketing is missed/happening, customers are told, etc...).

I've been hearing this rule for years now, and I think the coefficient is increasing. It started at 1.5x, now it's at 3x... Is this just me?

Maybe the coefficient is related to your age. You got older, so there is more wisdom around. ;)

I'd say this is Parkinson's Law at play

I'm such an optimist! I multiply by 2.2.

That's a recursive definition (estimate * 3) = ((estimate * 3) * 3) = (((estimate * 3) * 3) * 3)... But if you do that for a few years, "your honest and concise estimation" starts to grow because you've seen how it usually takes longer than expected, and your coefficient can approach 1.

I couldn't agree more. This is what I do.

I multiply by 4. Specifically, giving estimates on when features will be deployed/usable by end users.

yes, going from identification of the bug/idea to the solution in end users hands is a lot different than just the coding estimate. On teams with multiple levels of management both engineering side and customer side the actual code required to fix/implement the solution is such a small part of the overall effort you could, ironically, consider it immaterial.