3 ms·
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
by 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.)