6 ms·

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

by hnzix 8y ago

PeterisP 8y ago
An approach that gives very similar results to yours but is more scientific is to multiply the initial estimates by e (2.718). Or, if you're conservative, then by pi.
- leethargo 8y ago
  The above approach uses the factor 2.2. Why would your factors be any better?
  - ajuc 8y ago
    Nitpick: x * 2 * 1.2 == x * 2.4, not 2.2
    - apaatsio 8y ago
      Extended nitpick: Technically, they only said "then add 20%". They didn't specify of what that 20% is. It's up to interpretation whether they mean 20% of the original value or the doubled value.
  - alexgmcm 8y ago
    Wouldn't it be 2.4 as you are adding 20% of the already doubled estimate?
    - spurgu 8y ago
      Yes.
  - anoncake 8y ago
    2.2 is just an arbitrary number. e is also just an arbitrary number, but it looks like someone calculated it using sophisticated math.
  - skrebbel 8y ago
    Because e is more scientific.
    - TheOtherHobbes 8y ago
      Semi-seriously, e is a number defined by recursive growth. So if you estimate to Level 1, and then break down to Level 2 sub-tasks, then Level 3, your estimate will be out by the same amount each time. and your total error will be a multiplicative series. If you have an infinite number of levels - which is reasonable for most real-world projects, although this may not be obvious in the planning stages - e will get you nicely in the ballpark.
thatoneuser 8y ago
Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.
- nnq 8y ago
  220% also works fine if each one of the projects is "practically unique" to you / the team... this happens >50% of the time in the real world, imo, because some fields have very little transferable skills/experience from project to project... a large percent of stuff is genuinely new every time and never repeats even if it's "basically the same thing as that other project"! (Or team composition changes.) Problem is the fact that you can only justify with a straight-face 45% (100%/220%) of the estimate you give to the client... Then you need to get clever at "bluffing" your way at "inventing" another extra +35% of work that you can't imagine/explain, but you know for sure that will come out of the blue - you know there's this extra 35% work needed for sure, you just have no idea what this work will be. Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. There's two ways to see the same math: (1) 45% + 35% + 20% = 100% (2) 100% + 100% + 20% = 220% The world would be a much better place if clients / managers / project owners etc. would just accept that 55% of time & cost for software dev is unknown-unknowns type of unexplainable/unimaginable-at-project-start-stage-work. That's just how it is! If the problem was really clearly defined and understood, there would likely already be an off-the-shelf software solution for it that could be used instead of paying developers to build custom software! If we could just be honest with people and show them formula (2) instead of a make-up-ladden version of (1). But people don't, so we get to play the damn elegant-bullshitting game over and over again...
  - Roark66 8y ago
    >Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. This is how I always have done it across multiple jobs and I always called that extra contingency. Depending on the project I sometimes had to ask for over 50% of the total as contingency. If anyone queried it I would explain that it is very likely we'll need it based on my experience of many other projects. Then the client would either accept it as is, or they would want to split the proposal into "what we will definitely pay for" and "what we will pay for only when it is actually needed" which is also fine for both sides if proper progress reporting has been agreed in advance. Someone could think that no client would agree to such a contract as it would open them to be taken advantage of by an unscrupulous supplier, but at the end of the day what matters in business is trust. If a client doesn't trust the supplier they shouldn't hire them. And in all my previous projects I never met an engineer or developer that would deliberately use up the contingency time when it is not needed as everyone knows the availability of this extra time might come very important towards the end of the project.
d--b 8y ago
Or you could just multiply by 2.4 ... I used to do 2.5, I read somewhere 2.5 was fairly common
XorNot 8y ago
Triple it. Then triple that if to do it you have to go across team boundaries.
- bigiain 8y ago
  One of my funny-not-funny jokes is "Double it then change up to the next unit of measure" So "I can do that in 3 minutes!" becomes 6 hours. 2 hours become 4 days. 3 days becomes 6 weeks. 2 weeks becomes 4 months...
jspash 8y ago
A professor of mine at university taught us the same thing. It's one of the most valuable things I learned and it is uncannily accurate. Even after 30 years in industry I still fall back on this formula with great results. Sadly, managers want to believe that you put more effort into estimating deadlines so I'll just whip up a gannt chart retroactively based on the 2/20 rule and they're happy.
- growtofill 8y ago
  > Even after 30 years in industry I still fall back on this formula with great results. Isn't this Parkinson's law in action, i.e. work expands to fill the time available for its completion? That would mean you overestimate up to 2.4x each time. Edit: math.
  - hnzix 8y ago
    > work expands to fill the time available for its completion Oh, so if I estimate every task as 1 minute I'll finish really quickly? The 2.4x is to overcome one's innate overoptimism (even if you see yourself as a pessimist), and to add contingency for unplanned complexity, bugs and general overhead. It's a rule of thumb, not an immutable law, so if one has completed a similar task many times then less padding is needed.
leethargo 8y ago
I know it a little different, where you double it, but then a fixed offset, say 1 week, rather than 20%.
neilwilson 8y ago
I've worked on twice my gut feel for years. It's generally pretty near the mark. Humans are optimistic by nature. Even somebody as pessimistic as me.
maxxxxx 8y ago
My number is 5. Maybe my estimates tend to be a little optimistic :-). But in general I can look at something for a few minutes, make a quick estimate (maybe ask somebody else), multiply by 5 and be pretty close to the eventual time it will take.
fouc 8y ago
multiplying by 3 seems to cause the scenario of coming in under deadline and looking like a hero.
CraneWorm 8y ago
I multiply my estimates by the number of people involved.
stronglikedan 8y ago
If that 20% isn't for project management, then add another 10-20% for that, based on experience from previous projects for the same stakeholders. My similar rule of thumb is to multiply my estimate by 2.5, before adding the project management percentage. Of course, if it's something we've done before, it's more along the lines of 1.5 to 2.
JustSomeNobody 8y ago
I close to double mine, but it also depends on the tasks. Some tasks I just know I'll complete in 1X my estimate. I do have a rule that nothing is ever estimated at less than 2 hours; no matter how small the task. Invariably, any time I have broken that rule, someone has checked in code that won't build (or something similar) and I have to spend time dealing with that. I notice some devs like to underestimate to make them look more productive. Most of those tend to spend a lot of time fixing bugs that QA pushes back to them. They sometimes spend ever more time arguing that it's not their bug.
philpem 8y ago
Your boss just called. They said to tell you to stop padding your estimates...
jsight 8y ago
Oh, the Scotty Factor approach to estimating?

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

by hnzix 8y ago

My rule of thumb: take your estimate, double it, then add 20%. I'm not joking.

An approach that gives very similar results to yours but is more scientific is to multiply the initial estimates by e (2.718). Or, if you're conservative, then by pi.

leethargo 8y ago
The above approach uses the factor 2.2. Why would your factors be any better?
- ajuc 8y ago
  Nitpick: x * 2 * 1.2 == x * 2.4, not 2.2
  - apaatsio 8y ago
    Extended nitpick: Technically, they only said "then add 20%". They didn't specify of what that 20% is. It's up to interpretation whether they mean 20% of the original value or the doubled value.
- alexgmcm 8y ago
  Wouldn't it be 2.4 as you are adding 20% of the already doubled estimate?
  - spurgu 8y ago
    Yes.
- anoncake 8y ago
  2.2 is just an arbitrary number. e is also just an arbitrary number, but it looks like someone calculated it using sophisticated math.
- skrebbel 8y ago
  Because e is more scientific.
  - TheOtherHobbes 8y ago
    Semi-seriously, e is a number defined by recursive growth. So if you estimate to Level 1, and then break down to Level 2 sub-tasks, then Level 3, your estimate will be out by the same amount each time. and your total error will be a multiplicative series. If you have an infinite number of levels - which is reasonable for most real-world projects, although this may not be obvious in the planning stages - e will get you nicely in the ballpark.

thatoneuser 8y ago

Eh. I've been successful adding 20% in. I feel like if you have to double first (meaning your end result is 220% of what you originally estimated) then you aren't learning from previous mistakes. Maybe 220 is appropriate for the first time you do work or work with a certain team tho.

nnq 8y ago
220% also works fine if each one of the projects is "practically unique" to you / the team... this happens >50% of the time in the real world, imo, because some fields have very little transferable skills/experience from project to project... a large percent of stuff is genuinely new every time and never repeats even if it's "basically the same thing as that other project"! (Or team composition changes.) Problem is the fact that you can only justify with a straight-face 45% (100%/220%) of the estimate you give to the client... Then you need to get clever at "bluffing" your way at "inventing" another extra +35% of work that you can't imagine/explain, but you know for sure that will come out of the blue - you know there's this extra 35% work needed for sure, you just have no idea what this work will be. Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. There's two ways to see the same math: (1) 45% + 35% + 20% = 100% (2) 100% + 100% + 20% = 220% The world would be a much better place if clients / managers / project owners etc. would just accept that 55% of time & cost for software dev is unknown-unknowns type of unexplainable/unimaginable-at-project-start-stage-work. That's just how it is! If the problem was really clearly defined and understood, there would likely already be an off-the-shelf software solution for it that could be used instead of paying developers to build custom software! If we could just be honest with people and show them formula (2) instead of a make-up-ladden version of (1). But people don't, so we get to play the damn elegant-bullshitting game over and over again...
- Roark66 8y ago
  >Then finally you can say with a straight face that 20% of estimated time is for unforseen circumstances. This is how I always have done it across multiple jobs and I always called that extra contingency. Depending on the project I sometimes had to ask for over 50% of the total as contingency. If anyone queried it I would explain that it is very likely we'll need it based on my experience of many other projects. Then the client would either accept it as is, or they would want to split the proposal into "what we will definitely pay for" and "what we will pay for only when it is actually needed" which is also fine for both sides if proper progress reporting has been agreed in advance. Someone could think that no client would agree to such a contract as it would open them to be taken advantage of by an unscrupulous supplier, but at the end of the day what matters in business is trust. If a client doesn't trust the supplier they shouldn't hire them. And in all my previous projects I never met an engineer or developer that would deliberately use up the contingency time when it is not needed as everyone knows the availability of this extra time might come very important towards the end of the project.

d--b 8y ago

Or you could just multiply by 2.4 ... I used to do 2.5, I read somewhere 2.5 was fairly common

XorNot 8y ago

Triple it. Then triple that if to do it you have to go across team boundaries.

bigiain 8y ago
One of my funny-not-funny jokes is "Double it then change up to the next unit of measure" So "I can do that in 3 minutes!" becomes 6 hours. 2 hours become 4 days. 3 days becomes 6 weeks. 2 weeks becomes 4 months...

jspash 8y ago

A professor of mine at university taught us the same thing. It's one of the most valuable things I learned and it is uncannily accurate. Even after 30 years in industry I still fall back on this formula with great results. Sadly, managers want to believe that you put more effort into estimating deadlines so I'll just whip up a gannt chart retroactively based on the 2/20 rule and they're happy.

growtofill 8y ago
> Even after 30 years in industry I still fall back on this formula with great results. Isn't this Parkinson's law in action, i.e. work expands to fill the time available for its completion? That would mean you overestimate up to 2.4x each time. Edit: math.
- hnzix 8y ago
  > work expands to fill the time available for its completion Oh, so if I estimate every task as 1 minute I'll finish really quickly? The 2.4x is to overcome one's innate overoptimism (even if you see yourself as a pessimist), and to add contingency for unplanned complexity, bugs and general overhead. It's a rule of thumb, not an immutable law, so if one has completed a similar task many times then less padding is needed.

leethargo 8y ago

I know it a little different, where you double it, but then a fixed offset, say 1 week, rather than 20%.

neilwilson 8y ago

I've worked on twice my gut feel for years. It's generally pretty near the mark. Humans are optimistic by nature. Even somebody as pessimistic as me.

maxxxxx 8y ago

My number is 5. Maybe my estimates tend to be a little optimistic :-). But in general I can look at something for a few minutes, make a quick estimate (maybe ask somebody else), multiply by 5 and be pretty close to the eventual time it will take.

fouc 8y ago

multiplying by 3 seems to cause the scenario of coming in under deadline and looking like a hero.

CraneWorm 8y ago

I multiply my estimates by the number of people involved.

stronglikedan 8y ago

If that 20% isn't for project management, then add another 10-20% for that, based on experience from previous projects for the same stakeholders. My similar rule of thumb is to multiply my estimate by 2.5, before adding the project management percentage. Of course, if it's something we've done before, it's more along the lines of 1.5 to 2.

JustSomeNobody 8y ago

I close to double mine, but it also depends on the tasks. Some tasks I just know I'll complete in 1X my estimate. I do have a rule that nothing is ever estimated at less than 2 hours; no matter how small the task. Invariably, any time I have broken that rule, someone has checked in code that won't build (or something similar) and I have to spend time dealing with that. I notice some devs like to underestimate to make them look more productive. Most of those tend to spend a lot of time fixing bugs that QA pushes back to them. They sometimes spend ever more time arguing that it's not their bug.

philpem 8y ago

Your boss just called. They said to tell you to stop padding your estimates...

jsight 8y ago

Oh, the Scotty Factor approach to estimating?