7 ms·

A big problem is that estimates given by developers are never treated as estimates but rather as quotes . If you miss your estimate then your employer may expec

by pylua 5y ago

A big problem is that estimates given by developers are never treated as estimates but rather as quotes . If you miss your estimate then your employer may expect you to work extra hours to make up for the gap . Best strategy is to under promise over deliver .

beckingz 5y ago
Even estimates that are requested explicitly as estimates and not quotes have a tendency to be used for planning other dependencies. Once other dependencies are scheduled around a estimate, missing that deadline incurs rescheduling costs so no one wants to see it missed.
- bengale 5y ago
  Some of my biggest arguments as a lead were when I'd sit in one meeting and my team would be promised that these estimates weren't going to be held against them and its just for a rough understanding. Then I'd go to the next meeting where those 'project managers' would be using the estimates to try and plan months into the future, as if those estimates were 100% accurate. Then when it turns out estimates are out, I'm stuck in another meeting where they melt down about how they're going to explain overruns to their bosses. Utterly predictable madness. Then they had the nerve to get arsey when we started refusing to estimate.
  - hateful 5y ago
    This is my experience, over and over - to the point where I often get to the point the article states as "just … give up". Then there's the "let's split it up into pieces first". This is where, instead of rolling one 100-sided die, we flip 100 coins to get a better estimate. But my absolute favorite is when the Project Manager asks for an estimate and you give a number and if they think it's too high or too low, they will keep asking until you give them the number they were looking for in the first place. Why even ask? Because now it's your fault if it's wrong! (side note: There are solutions to these things and they are definitely not the right way to do things and are signs of a toxic environment - but there is hope!)
  - marcus_holmes 5y ago
    This is part of the reason I refuse to give estimates. As TFA says, you do get better conversations with the rest of the business if you refuse to give an estimate.
- tikhonj 5y ago
  And yet, in my experience, even people who recognize this focus hard to improving estimates and "accountability", but rarely seriously try to reduce dependencies. I tend to operate on the opposite principle, to the point that I believe it is worth doing substantial amounts of seemingly redundant or throw-away[1] work to turn hard dependencies into soft dependencies. But you have to have both a business organization and a software architecture that can support this. [1]: Really, "throw-away" just means "temporary", and all our work is temporary—the question is just how temporary.
ape4 5y ago
You can give a range - eg 3 to 5 months.
- marcus_holmes 5y ago
  I tried that, and it was almost (but not quite) invariably held to be the lowest of the range, and still construed as a deadline. "3-5 months" becomes "3 months or we have to reschedule other stuff".
rorykoehler 5y ago
Nothing would get built if 100% accurate estimates were given. Finance would say it's too expensive and that would be that.
- atatatat 5y ago
  Awesome. I just found another competitive advantage in my startups.
yelling_cat 5y ago
I learned early in my career to never give an executive a completion date or time estimate I hadn't thought long and hard about and had full confidence in. They won't remember any of the contingencies you tacked onto your estimate or the additional features they insisted on adding to the project after you talked, but they'll never forget when you said it would be done. It's far better to annoy them in the short term by saying what you'll need to provide an accurate time frame than it is to guestimate something that will bite you later.
FinanceAnon 5y ago
80/20 rule: “Nothing – and I mean nothing – in IT takes less than 80 hours, and whatever you think it’ll actually take, multiply it by 20, and tell management that. You see, 80/20.”
darekkay 5y ago
That's why scrum changed the wording from "estimate" to "forecast". It's more like a weather forecast: you'll often get close, but sometimes it's completely off.

by pylua 5y ago

beckingz 5y ago

Even estimates that are requested explicitly as estimates and not quotes have a tendency to be used for planning other dependencies. Once other dependencies are scheduled around a estimate, missing that deadline incurs rescheduling costs so no one wants to see it missed.

bengale 5y ago
Some of my biggest arguments as a lead were when I'd sit in one meeting and my team would be promised that these estimates weren't going to be held against them and its just for a rough understanding. Then I'd go to the next meeting where those 'project managers' would be using the estimates to try and plan months into the future, as if those estimates were 100% accurate. Then when it turns out estimates are out, I'm stuck in another meeting where they melt down about how they're going to explain overruns to their bosses. Utterly predictable madness. Then they had the nerve to get arsey when we started refusing to estimate.
- hateful 5y ago
  This is my experience, over and over - to the point where I often get to the point the article states as "just … give up". Then there's the "let's split it up into pieces first". This is where, instead of rolling one 100-sided die, we flip 100 coins to get a better estimate. But my absolute favorite is when the Project Manager asks for an estimate and you give a number and if they think it's too high or too low, they will keep asking until you give them the number they were looking for in the first place. Why even ask? Because now it's your fault if it's wrong! (side note: There are solutions to these things and they are definitely not the right way to do things and are signs of a toxic environment - but there is hope!)
- marcus_holmes 5y ago
  This is part of the reason I refuse to give estimates. As TFA says, you do get better conversations with the rest of the business if you refuse to give an estimate.
tikhonj 5y ago
And yet, in my experience, even people who recognize this focus hard to improving estimates and "accountability", but rarely seriously try to reduce dependencies. I tend to operate on the opposite principle, to the point that I believe it is worth doing substantial amounts of seemingly redundant or throw-away[1] work to turn hard dependencies into soft dependencies. But you have to have both a business organization and a software architecture that can support this. [1]: Really, "throw-away" just means "temporary", and all our work is temporary—the question is just how temporary.

ape4 5y ago

You can give a range - eg 3 to 5 months.

marcus_holmes 5y ago
I tried that, and it was almost (but not quite) invariably held to be the lowest of the range, and still construed as a deadline. "3-5 months" becomes "3 months or we have to reschedule other stuff".

rorykoehler 5y ago

Nothing would get built if 100% accurate estimates were given. Finance would say it's too expensive and that would be that.

atatatat 5y ago
Awesome. I just found another competitive advantage in my startups.

yelling_cat 5y ago

I learned early in my career to never give an executive a completion date or time estimate I hadn't thought long and hard about and had full confidence in. They won't remember any of the contingencies you tacked onto your estimate or the additional features they insisted on adding to the project after you talked, but they'll never forget when you said it would be done. It's far better to annoy them in the short term by saying what you'll need to provide an accurate time frame than it is to guestimate something that will bite you later.

FinanceAnon 5y ago

80/20 rule: “Nothing – and I mean nothing – in IT takes less than 80 hours, and whatever you think it’ll actually take, multiply it by 20, and tell management that. You see, 80/20.”

darekkay 5y ago

That's why scrum changed the wording from "estimate" to "forecast". It's more like a weather forecast: you'll often get close, but sometimes it's completely off.