13 ms·

I am 20 years in development business now. This simple rule of thumb works for me and the team: (Your honest and concise estimation) * 3 There are just to many

I am 20 years in development business now. This simple rule of thumb works for me and the team: (Your honest and concise estimation) * 3 There are just to many unknowns you cannot foresee. Software development is complex.

kilroy123 6y ago
I couldn't agree more. This is what I do.
OneGuy123 6y ago
This, the famous "prediction* Pi" rule seems to be correct also in my experience. I make the most optimistic prediction and then * PI.
curiousllama 6y ago
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?
- Aldipower 6y ago
  Maybe the coefficient is related to your age. You got older, so there is more wisdom around. ;)
- impy 6y ago
  I'd say this is Parkinson's Law at play
kthejoker2 6y ago
I'm such an optimist! I multiply by 2.2.
matwood 6y ago
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...).
TehShrike 6y ago
I multiply by 4. Specifically, giving estimates on when features will be deployed/usable by end users.
- chasd00 6y ago
  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.
nikolaj 6y ago
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.
elwell 6y ago
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.
fphilipe 6y ago
Great anecdote posted here a few years ago: https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe https://www.quora.com/Why-are-software-development-task-esti...
- Aldipower 6y ago
  Great read!! :D

kilroy123 6y ago

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

OneGuy123 6y ago

This, the famous "prediction* Pi" rule seems to be correct also in my experience. I make the most optimistic prediction and then * PI.

curiousllama 6y ago

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?

Aldipower 6y ago
Maybe the coefficient is related to your age. You got older, so there is more wisdom around. ;)
impy 6y ago
I'd say this is Parkinson's Law at play

kthejoker2 6y ago

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

matwood 6y ago

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...).

TehShrike 6y ago

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

chasd00 6y ago
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.

nikolaj 6y ago

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.

elwell 6y ago

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.

fphilipe 6y ago

Great anecdote posted here a few years ago: https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe https://www.quora.com/Why-are-software-development-task-esti...

Aldipower 6y ago
Great read!! :D