3 ms·

Even on the store point: I might notice I’m low on fuel and fill up on the way. Easily turns a 15-minute errand into 20 minutes. Estimations in the context of a

Even on the store point: I might notice I’m low on fuel and fill up on the way. Easily turns a 15-minute errand into 20 minutes. Estimations in the context of a software project are similar to a promise that my trip to the store will only be 15 minutes which I’m held to even if I notice the low fuel gauge.

ozim 3y ago
I like the store metaphor. Shopping list is set and I should be in and out in 15 mins but it turns out there is no ketchup - so do I go to another store to get ketchup or mustard will do. Product owner my Girlfriend has to decide because she is doing the cooking and will present it to customers our guests, and she knows if they like mustard or not because she talks to them more often than I do. But yeah going to another store might make dinner late and I cannot know this until I actually arrive at the store that there is no ketchup on the shelves.
- interactivecode 3y ago
  Its a good metaphor also because if you have an appointment in 20min you would never go to the shop 15min before. Yet managers will force you still out and to the shop because of your time estimate.
Volundr 3y ago
Part of estimating is accounting for those contingencies. Given above, depending on my audience the above estimate will be either 30 minutes, or 15 minutes but could be as long as 30 depending on these factors. Part of estimating is accounting for the setbacks one can (reasonably) expect to see, to give the other party a timeframe within which they can be (reasonably) certain it will be done. Of course there could be a fire on-route causing a jam that turns your 15 minute trip into 2 hours, but that's sufficiently unlikely it's probably not worth building into your estimate (but could be depending on the stakes involved! If someone is going to die you should probably factor this in so we can plan for that contingency). In that instance instead you need to communicate when it happens so that everyone involved can recalibrate.
- lcnPylGDnU4H9OF 3y ago
  > the above estimate will be either 30 minutes Yeah, I had a PM who taught me to do this by doing it themself. My estimates are actually just doubled from how much I expect it to take when I know the design and can work with no distractions. I’ve also worked with managers who “negotiate” as others sometimes describe. Of these I see good and bad. One who was aware of short- and long-term goals of our team and asked for estimates so they could decide what features we need to include; another who already promised the features and the deadline and is asking me to tell them that they did not overpromise despite my observations. (“I don’t believe I’ll be able to deliver those features by that date.”) Others in between, including some who don’t like being told explicitly that I double the estimate. Worse still, the one who halves it as if to correct for some mistake. I guess the moral is that developers aren’t the only critical party when it comes to communicating estimates. Managers do their own job; good, bad, or otherwise. ------- > depending on my audience Other than some managers I assume another developer or a good technical manager, and it’s a good approach. Sounds at least similar to explicitly stating that you doubled your “no distractions” estimate. Too bad it seems that an unfortunate lot of people work with the bad “negotiating” type who might even be so disrespectful as to correct their co-worker’s mistaken opinion -- which they asked for! (Not to leave this as advice for the parent commenter. Just wrote some thoughts and figure I can share for anyone who might get value from them.)

ozim 3y ago

I like the store metaphor. Shopping list is set and I should be in and out in 15 mins but it turns out there is no ketchup - so do I go to another store to get ketchup or mustard will do. Product owner my Girlfriend has to decide because she is doing the cooking and will present it to customers our guests, and she knows if they like mustard or not because she talks to them more often than I do. But yeah going to another store might make dinner late and I cannot know this until I actually arrive at the store that there is no ketchup on the shelves.

interactivecode 3y ago
Its a good metaphor also because if you have an appointment in 20min you would never go to the shop 15min before. Yet managers will force you still out and to the shop because of your time estimate.

Volundr 3y ago

Part of estimating is accounting for those contingencies. Given above, depending on my audience the above estimate will be either 30 minutes, or 15 minutes but could be as long as 30 depending on these factors. Part of estimating is accounting for the setbacks one can (reasonably) expect to see, to give the other party a timeframe within which they can be (reasonably) certain it will be done. Of course there could be a fire on-route causing a jam that turns your 15 minute trip into 2 hours, but that's sufficiently unlikely it's probably not worth building into your estimate (but could be depending on the stakes involved! If someone is going to die you should probably factor this in so we can plan for that contingency). In that instance instead you need to communicate when it happens so that everyone involved can recalibrate.

lcnPylGDnU4H9OF 3y ago
> the above estimate will be either 30 minutes Yeah, I had a PM who taught me to do this by doing it themself. My estimates are actually just doubled from how much I expect it to take when I know the design and can work with no distractions. I’ve also worked with managers who “negotiate” as others sometimes describe. Of these I see good and bad. One who was aware of short- and long-term goals of our team and asked for estimates so they could decide what features we need to include; another who already promised the features and the deadline and is asking me to tell them that they did not overpromise despite my observations. (“I don’t believe I’ll be able to deliver those features by that date.”) Others in between, including some who don’t like being told explicitly that I double the estimate. Worse still, the one who halves it as if to correct for some mistake. I guess the moral is that developers aren’t the only critical party when it comes to communicating estimates. Managers do their own job; good, bad, or otherwise. ------- > depending on my audience Other than some managers I assume another developer or a good technical manager, and it’s a good approach. Sounds at least similar to explicitly stating that you doubled your “no distractions” estimate. Too bad it seems that an unfortunate lot of people work with the bad “negotiating” type who might even be so disrespectful as to correct their co-worker’s mistaken opinion -- which they asked for! (Not to leave this as advice for the parent commenter. Just wrote some thoughts and figure I can share for anyone who might get value from them.)