7 ms·

Guess what number they'll accept and double it, put up a fight when they halve it, blame someone else when you miss it, and take the credit when you hit it. At

Guess what number they'll accept and double it, put up a fight when they halve it, blame someone else when you miss it, and take the credit when you hit it. At most companies estimates are about control, expectation management, and blame distribution and not about information discovery. Most people really suck at expectation management, much more than they suck at estimating work.

honor_roller64 9y ago
Triple it and then you have some headroom for when they halve it.
- justherefortart 9y ago
  I make my best guess and quadruple it. That tends to be the most accurate I get. I underestimate everything and also forget interruptions, new "on fire" issues, life events (turkey day, etc) and everything else. So instead of worrying about all the stuff I'm missing, I just give my best guess and say it's that. A guess. If you want to hold me to an estimate, I need weeks of planning to get back to you. In that time I can do the missing BA work, mock up what needs to be done and get a better estimate, which I'll still quadruple.
  - ghaff 9y ago
    An engineering manager I used to work with would drive me crazy. He had this "methodology" he referred to as a 90% schedule but it was a 90% confidence schedule only in the sense of no one ever getting sick for a couple of days, tests not failing, no hardware being defective, etc. etc. It won't come as a surprise that this schedule was basically never met.
- patrickmay 9y ago
  Double it and go to the next higher units. 4 hours? That's 8 days.
- paulie_a 9y ago
  Exactly. Never give a be range either. The lowest number is now your estimate.
MereInterest 9y ago
Sounds a lot like the scene in Star Trek: The Next Generation, where Geordi La Forge meets Scotty. > Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours. > [La Forge goes back to work; Scotty follows slowly] > Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want. > Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour. > Scotty: How long will it really take? > Lt. Commander Geordi La Forge: An hour! > Scotty: Oh, you didn't tell him how long it would really take, did ya? > Lt. Commander Geordi La Forge: Well, of course I did. > Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.
- gist 9y ago
  Cliche: "Deliver more than you promise"
  - ghaff 9y ago
    Or "Underpromise, overdeliver." Sometimes there are legitimate reasons to come up with schedules that are as accurate as you can make them, understanding that stuff almost always happens. Sometimes a project or some dependencies don't make sense if they can't be done by a particular date. But, yeah, it's good advice in general. For most of the work I do (not programming), I have a pretty good sense of the minimum time I need and I almost always significantly pad that to accommodate priority interrupts or just so I can take a bit of extra time if I feel the task warrants it.
- huffpopo 9y ago
  I remember that, made me laugh and wonder; was Scotty really giving it all she's got.
- thaumaturgy 9y ago
  I always hated that scene, because it fundamentally changed the character of Mr. Scott from engineer to engineering manager. Which, he was, but that wasn't what made his character so compelling to begin with. LaForge was a competent engineering manager. The writers tended to focus more on the character's people management skills (and, sometimes, terrible personal relationship stuff). He kept things running smoothly. He was smart. You could imagine a detailed maintenance work log for every system on the ship, and there'd be no gaps in it ever since he took the position of chief engineer. But while Scotty cared about his staff, it was the machinery that he knew inside and out. He never needed to conjure up a hologram of the designer of the warp engines, because he knew them as well as anyone else. His maintenance logs would have gaps because he'd know which things actually needed regular attention, and which ones were just bureaucratic nonsense. He didn't just understand all of it on the technician level, but on the theoretical level too, enabling him to pull off some unlikely saves. He actually was a miracle worker and maybe one of the best fictional representations of an engineer, and that one scene was written to make him look a little more like a bureaucrat.
madengr 9y ago
PM always wants ROMs (Rough Order of Magnitude estimates), then they bitch when actual project cost is under 5%, or head will roll if it's 1 penny over. Not understanding an order of magnitude, much less a rough one, is why they are not in engineering. They don't like it when I say a ROM is roughly accurate to 0.1X to 10X cost.
acbabis 9y ago
I once read someone give similar advice about estimation. What stuck with me most is that if someone pressures you to change an estimate, it's no longer an estimate. Most managers don't actually want estimates.
- ghaff 9y ago
  Many moons ago when I was doing a combination of engineering and project management, I had to come up with a schedule for a shipyard project. Which I dutifully did. It was probably two months or something like that. Ran it up the flagpole. It got cut in half. Fortunately I didn't need to change the schedule I had drawn up. I just said each box is now half a day. (This was before we used computers for this sort of thing.) As I recall, the job came in very close to my initial estimate.
jwatte 9y ago
It's only about control in the sense that it matters what a business invests in. If I believe that feature X will be worth $Y, whether I invest in that, or some other feature, depends a whole lot on how much I expect to pay to get X. Opportunity cost is the important metric here, not just absolute RoI.
taeric 9y ago
Don't do point estimates. Pretty much period. Instead, try actually estimating the work. List components touched. List technologies involved. List screens needed. All of these are measurable. A point estimate is too easy to get wrong and impossible to question.
- valuearb 9y ago
  Not sure what you mean by point estimates, because point estimates are the only way to accurately gauge the work in a project. Elaborate work estimations are a fools errand. No one can argue that you can make far more accurate estimates by spending 50% of your time doing research for estimates instead of 2% of your time. But spending 2% of your time on estimates also means you'll finish every project twice as fast.
  - taeric 9y ago
    Point estimate, in this case, is reducing down to a single number. If I'm using the wrong term, please correct me. Now many people doing this use a "point system" where they escalate the allowed votes as you go up. This is a neat heuristic that accounts for some uncertainty. But it really only boils down the estimates to the easy to estimate tasks. Which are often not worth estimating. I'm not claiming to be elaborate. But do realize if someone estimates a house project is large, I will have less faith in their estimate compared to someone estimating it will take about 300 square feet of tile, plus for gallons of paint and probably to gallons of mortar. One shows they have thought and didn't gut shot it. Even better, we have something to actually burn down in the supplies. We can also gauge it with previous jobs to know how long it took to use that much supplies. Software is tougher, because we don't have the same supplies. But this is why you don't list lines of code, but required screens, technical integrations, and general features. Agreed that you don't want to get too elaborate. But also don't give me some stupid t-shirt sizing or other nonsense. Not the least of the reasons why, is negotiating a size is dumb. There are literally no reasons not to convince someone they estimated high. However, cutting an integration is a choice that has obvious downsides to account for any speed up in delivery. Even better, it is empowering to choose what you won't deliver, instead of having it chosen for you.
mratzloff 9y ago
I'll share another perspective. Execs view it as being able to make informed decisions about where to spend the company's time and money. Let's say you have projects A and B you want to do, and you've estimated revenues from each at $11 MM and $4 MM. You really want to do A, since it would establish a business relationship with a new strategic partner, but estimates come back that A will take 16 weeks and B will take 4 weeks. You only have time to focus on one project at a time, so you choose B to try to capture a quick turnaround before moving onto A. Plus it would make an existing partner happy. Execs know from experience that the engineering estimates usually suck. Sometimes they're really high and sometimes they're really low. Execs decide as long as B doesn't exceed 5 weeks, we're OK. They don't communicate this down the chain because if everyone knows 5 weeks is the "real" number they'll (grudgingly) accept, they are pretty sure someone somewhere in the chain will spend a week optimizing the test harness or refactoring the build process or something. At week 3, engineering says they're gonna need 2 more weeks. Execs: Sure. At week 4, engineering says they're gonna need 2 more weeks again. Execs are annoyed but now the work is mostly done, and everyone promises on their children's lives it will actually be done in 6 weeks, so they let it finish. At week 5, we're still on track for week 6. Execs: Sure. At week 6, we're gonna need another week. Execs: Whatever. At this point they've abandoned all faith in this engineering team. They re-task some other critical part of the business with beginning work on project A. Some part of the business suffers. B actually takes 7 weeks when all is said and done. Execs wouldn't have bothered with it if they knew that up front. Everyone involved in B takes a reputation hit: the product manager, the project manager, the engineering manager, and the engineers themselves. The people who blame others get an even bigger reputation hit. Now there's pressure from some sides of the exec table to make up time on project A and get the estimate below 16 weeks from a team that had nothing to do with B. Happily for everyone but the first team, it turns out the other team is able to get project A out the door in just 12 weeks. Everyone on the first team takes another reputation hit. You might say that the root problem was the estimate for B was too low. That is a problem, but the fact that the estimate for A was 25% is equally problematic. Had either estimate been more accurate, the company would have focuses on A first. All of these execs are accountable to the CEO, who's accountable to the board. The CPO or CTO or whoever are not escaping unscathed from this, because at the next board meeting the CEO has to answer for why project A was delayed into Q2.
valuearb 9y ago
Never give time estimates. But if you are forced to give them, never give a single number. Use ranges. Your range for a confident estimate should be roughly 4x between the fastest and longest components. For example, 1 to 4 hours for a task you are very confident about. For things you have less confidence on, your range should be closer to 8X. Why do this? Because wide ranges are the ONLY accurate software engineering time estimates. You need to communicate the inherent lack of precision in any estimate. For every time estimate you don't know 1) How many hours a day you'll be allowed to actually code, outside of meetings, standup, planning sessions, emergency bug fixes, etc, etc. 2) Which member of your team will actually end up doing it, the fastest one, the slowest one, or someone in between. 3) How many days will be lost to illness or personal issues. 4) How much the actual feature or story will change as it's developed and they realize the design is actual shit. 5) How much other code will need to be changed when you actually rip the lid off some of the older code it will interact with. etc. etc.
- Too 9y ago
  A good way to enforce this is to always estimate things in steps of 2^x. Eg you are not allowed to estimate something as taking 20 days, it's either 16 days or 32 days. That way it's obvious that the larger the estimate becomes the more inaccurate it is and you are forced to automatically double to 32 if your "inner" estimate is 17 days. Scrum has a similar technique only allowing Fibonacci numbers, I think the reasoning behind it is similar. Obviously the receiver of the estimate should know that you are using this method, otherwise they might start questioning you thinking this estimate should only be 17 for example.

honor_roller64 9y ago

Triple it and then you have some headroom for when they halve it.

justherefortart 9y ago
I make my best guess and quadruple it. That tends to be the most accurate I get. I underestimate everything and also forget interruptions, new "on fire" issues, life events (turkey day, etc) and everything else. So instead of worrying about all the stuff I'm missing, I just give my best guess and say it's that. A guess. If you want to hold me to an estimate, I need weeks of planning to get back to you. In that time I can do the missing BA work, mock up what needs to be done and get a better estimate, which I'll still quadruple.
- ghaff 9y ago
  An engineering manager I used to work with would drive me crazy. He had this "methodology" he referred to as a 90% schedule but it was a 90% confidence schedule only in the sense of no one ever getting sick for a couple of days, tests not failing, no hardware being defective, etc. etc. It won't come as a surprise that this schedule was basically never met.
patrickmay 9y ago
Double it and go to the next higher units. 4 hours? That's 8 days.
paulie_a 9y ago
Exactly. Never give a be range either. The lowest number is now your estimate.

MereInterest 9y ago

Sounds a lot like the scene in Star Trek: The Next Generation, where Geordi La Forge meets Scotty. > Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours. > [La Forge goes back to work; Scotty follows slowly] > Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want. > Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour. > Scotty: How long will it really take? > Lt. Commander Geordi La Forge: An hour! > Scotty: Oh, you didn't tell him how long it would really take, did ya? > Lt. Commander Geordi La Forge: Well, of course I did. > Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.

gist 9y ago
Cliche: "Deliver more than you promise"
- ghaff 9y ago
  Or "Underpromise, overdeliver." Sometimes there are legitimate reasons to come up with schedules that are as accurate as you can make them, understanding that stuff almost always happens. Sometimes a project or some dependencies don't make sense if they can't be done by a particular date. But, yeah, it's good advice in general. For most of the work I do (not programming), I have a pretty good sense of the minimum time I need and I almost always significantly pad that to accommodate priority interrupts or just so I can take a bit of extra time if I feel the task warrants it.
huffpopo 9y ago
I remember that, made me laugh and wonder; was Scotty really giving it all she's got.
thaumaturgy 9y ago
I always hated that scene, because it fundamentally changed the character of Mr. Scott from engineer to engineering manager. Which, he was, but that wasn't what made his character so compelling to begin with. LaForge was a competent engineering manager. The writers tended to focus more on the character's people management skills (and, sometimes, terrible personal relationship stuff). He kept things running smoothly. He was smart. You could imagine a detailed maintenance work log for every system on the ship, and there'd be no gaps in it ever since he took the position of chief engineer. But while Scotty cared about his staff, it was the machinery that he knew inside and out. He never needed to conjure up a hologram of the designer of the warp engines, because he knew them as well as anyone else. His maintenance logs would have gaps because he'd know which things actually needed regular attention, and which ones were just bureaucratic nonsense. He didn't just understand all of it on the technician level, but on the theoretical level too, enabling him to pull off some unlikely saves. He actually was a miracle worker and maybe one of the best fictional representations of an engineer, and that one scene was written to make him look a little more like a bureaucrat.

madengr 9y ago

PM always wants ROMs (Rough Order of Magnitude estimates), then they bitch when actual project cost is under 5%, or head will roll if it's 1 penny over. Not understanding an order of magnitude, much less a rough one, is why they are not in engineering. They don't like it when I say a ROM is roughly accurate to 0.1X to 10X cost.

acbabis 9y ago

I once read someone give similar advice about estimation. What stuck with me most is that if someone pressures you to change an estimate, it's no longer an estimate. Most managers don't actually want estimates.

ghaff 9y ago
Many moons ago when I was doing a combination of engineering and project management, I had to come up with a schedule for a shipyard project. Which I dutifully did. It was probably two months or something like that. Ran it up the flagpole. It got cut in half. Fortunately I didn't need to change the schedule I had drawn up. I just said each box is now half a day. (This was before we used computers for this sort of thing.) As I recall, the job came in very close to my initial estimate.

jwatte 9y ago

It's only about control in the sense that it matters what a business invests in. If I believe that feature X will be worth $Y, whether I invest in that, or some other feature, depends a whole lot on how much I expect to pay to get X. Opportunity cost is the important metric here, not just absolute RoI.

taeric 9y ago

Don't do point estimates. Pretty much period. Instead, try actually estimating the work. List components touched. List technologies involved. List screens needed. All of these are measurable. A point estimate is too easy to get wrong and impossible to question.

valuearb 9y ago
Not sure what you mean by point estimates, because point estimates are the only way to accurately gauge the work in a project. Elaborate work estimations are a fools errand. No one can argue that you can make far more accurate estimates by spending 50% of your time doing research for estimates instead of 2% of your time. But spending 2% of your time on estimates also means you'll finish every project twice as fast.
- taeric 9y ago
  Point estimate, in this case, is reducing down to a single number. If I'm using the wrong term, please correct me. Now many people doing this use a "point system" where they escalate the allowed votes as you go up. This is a neat heuristic that accounts for some uncertainty. But it really only boils down the estimates to the easy to estimate tasks. Which are often not worth estimating. I'm not claiming to be elaborate. But do realize if someone estimates a house project is large, I will have less faith in their estimate compared to someone estimating it will take about 300 square feet of tile, plus for gallons of paint and probably to gallons of mortar. One shows they have thought and didn't gut shot it. Even better, we have something to actually burn down in the supplies. We can also gauge it with previous jobs to know how long it took to use that much supplies. Software is tougher, because we don't have the same supplies. But this is why you don't list lines of code, but required screens, technical integrations, and general features. Agreed that you don't want to get too elaborate. But also don't give me some stupid t-shirt sizing or other nonsense. Not the least of the reasons why, is negotiating a size is dumb. There are literally no reasons not to convince someone they estimated high. However, cutting an integration is a choice that has obvious downsides to account for any speed up in delivery. Even better, it is empowering to choose what you won't deliver, instead of having it chosen for you.

mratzloff 9y ago

I'll share another perspective. Execs view it as being able to make informed decisions about where to spend the company's time and money. Let's say you have projects A and B you want to do, and you've estimated revenues from each at $11 MM and $4 MM. You really want to do A, since it would establish a business relationship with a new strategic partner, but estimates come back that A will take 16 weeks and B will take 4 weeks. You only have time to focus on one project at a time, so you choose B to try to capture a quick turnaround before moving onto A. Plus it would make an existing partner happy. Execs know from experience that the engineering estimates usually suck. Sometimes they're really high and sometimes they're really low. Execs decide as long as B doesn't exceed 5 weeks, we're OK. They don't communicate this down the chain because if everyone knows 5 weeks is the "real" number they'll (grudgingly) accept, they are pretty sure someone somewhere in the chain will spend a week optimizing the test harness or refactoring the build process or something. At week 3, engineering says they're gonna need 2 more weeks. Execs: Sure. At week 4, engineering says they're gonna need 2 more weeks again. Execs are annoyed but now the work is mostly done, and everyone promises on their children's lives it will actually be done in 6 weeks, so they let it finish. At week 5, we're still on track for week 6. Execs: Sure. At week 6, we're gonna need another week. Execs: Whatever. At this point they've abandoned all faith in this engineering team. They re-task some other critical part of the business with beginning work on project A. Some part of the business suffers. B actually takes 7 weeks when all is said and done. Execs wouldn't have bothered with it if they knew that up front. Everyone involved in B takes a reputation hit: the product manager, the project manager, the engineering manager, and the engineers themselves. The people who blame others get an even bigger reputation hit. Now there's pressure from some sides of the exec table to make up time on project A and get the estimate below 16 weeks from a team that had nothing to do with B. Happily for everyone but the first team, it turns out the other team is able to get project A out the door in just 12 weeks. Everyone on the first team takes another reputation hit. You might say that the root problem was the estimate for B was too low. That is a problem, but the fact that the estimate for A was 25% is equally problematic. Had either estimate been more accurate, the company would have focuses on A first. All of these execs are accountable to the CEO, who's accountable to the board. The CPO or CTO or whoever are not escaping unscathed from this, because at the next board meeting the CEO has to answer for why project A was delayed into Q2.

valuearb 9y ago

Never give time estimates. But if you are forced to give them, never give a single number. Use ranges. Your range for a confident estimate should be roughly 4x between the fastest and longest components. For example, 1 to 4 hours for a task you are very confident about. For things you have less confidence on, your range should be closer to 8X. Why do this? Because wide ranges are the ONLY accurate software engineering time estimates. You need to communicate the inherent lack of precision in any estimate. For every time estimate you don't know 1) How many hours a day you'll be allowed to actually code, outside of meetings, standup, planning sessions, emergency bug fixes, etc, etc. 2) Which member of your team will actually end up doing it, the fastest one, the slowest one, or someone in between. 3) How many days will be lost to illness or personal issues. 4) How much the actual feature or story will change as it's developed and they realize the design is actual shit. 5) How much other code will need to be changed when you actually rip the lid off some of the older code it will interact with. etc. etc.

Too 9y ago
A good way to enforce this is to always estimate things in steps of 2^x. Eg you are not allowed to estimate something as taking 20 days, it's either 16 days or 32 days. That way it's obvious that the larger the estimate becomes the more inaccurate it is and you are forced to automatically double to 32 if your "inner" estimate is 17 days. Scrum has a similar technique only allowing Fibonacci numbers, I think the reasoning behind it is similar. Obviously the receiver of the estimate should know that you are using this method, otherwise they might start questioning you thinking this estimate should only be 17 for example.