3 ms·

I'm the 'pointy-haired' boss and I usually don't take my engineering teams estimates at face value. I've learned to multiply the estimates to know when I can r

I'm the 'pointy-haired' boss and I usually don't take my engineering teams estimates at face value. I've learned to multiply the estimates to know when I can reasonably expect something to be completed. The multiplier is never less than 1.5. And I can see if they are making progress and where they might be hitting difficulties. (Most roadblocks have nothing to do with the tech. It's usually either some organisational barrier or a personal issue.)

karparov 2y ago
And since everybody knows that this is how management deals with estimates, there is no incentive to improve upon their own.
- lazide 2y ago
  The big thing is usually what do various folks mean by ‘improve’? ‘As small as possible’? (Aka optimistic) ‘As accurate as possible’? (Aka as low variance) ‘As conservative as possible’? (Aka least likely to ever be exceeded) ‘As cheap to estimate as possible’? (Aka lowest overhead) Most people have no idea which strategy they are even doing.
- sumanthvepa 2y ago
  True. But I'm not measuring their performance relative to their estimates. I'm measuring performance relative to their peers and their previous performance. So giving me a padded estimate won't make much of a difference. Obviously, judgements are deeply subjective, since no two programming tasks are ever identical or even alike, but if you code a lot like, me you have a pretty good idea of what constitutes good.
rswail 2y ago
"Double it and raise it to the next time unit" still works. A 1 hour job will take 2 days. A 1 day job will take 2 weeks. etc.
- orwin 2y ago
  For me that's only true for projects/fixes with low time unit. When I say 'it'll take a month', I usually took into account testing and deployment, so it usually take a month (and a week or two because I still overestimate myself). When I say 'it should take an hour/half a day/a day', yes you are definitely right, and my manager is in trouble.
  - rswail 2y ago
    Given the stupid focus on "stories have to be shrunk to fit a sprint" nonsense, you don't need to estimate more than 2 weeks at a time :)

karparov 2y ago

And since everybody knows that this is how management deals with estimates, there is no incentive to improve upon their own.

lazide 2y ago
The big thing is usually what do various folks mean by ‘improve’? ‘As small as possible’? (Aka optimistic) ‘As accurate as possible’? (Aka as low variance) ‘As conservative as possible’? (Aka least likely to ever be exceeded) ‘As cheap to estimate as possible’? (Aka lowest overhead) Most people have no idea which strategy they are even doing.
sumanthvepa 2y ago
True. But I'm not measuring their performance relative to their estimates. I'm measuring performance relative to their peers and their previous performance. So giving me a padded estimate won't make much of a difference. Obviously, judgements are deeply subjective, since no two programming tasks are ever identical or even alike, but if you code a lot like, me you have a pretty good idea of what constitutes good.

rswail 2y ago

"Double it and raise it to the next time unit" still works. A 1 hour job will take 2 days. A 1 day job will take 2 weeks. etc.

orwin 2y ago
For me that's only true for projects/fixes with low time unit. When I say 'it'll take a month', I usually took into account testing and deployment, so it usually take a month (and a week or two because I still overestimate myself). When I say 'it should take an hour/half a day/a day', yes you are definitely right, and my manager is in trouble.
- rswail 2y ago
  Given the stupid focus on "stories have to be shrunk to fit a sprint" nonsense, you don't need to estimate more than 2 weeks at a time :)