[ipnon]

I wonder how much more accurate estimations would be if we had engineers actually draw probability curves that are then aggregated and analyzed. As it stands now, having had some experience getting burned, I always give my estimate that's really at the tail end, and I have become exceedingly efficient at explaining why that estimate is how long it will "really take."

[Viliam1234]

Estimates somehow magically become commitments. Like, if you don't make it in the estimated time, it's your fault, you should have estimated bettter.

Okay, so suppose my best guess is that there is a 10% chance something could be done in a day, 80% chance it would take two or three days, and 10% chance it would take five days. What is supposed to be my "estimate"?

If I keep giving the longest time interval, I will seem like lazy and incompetent, because why am I always saying "five days" to tasks that everyone knows usually take only two or three days. But if I say "three days", then in those 10% when it actually takes five days, I have estimated wrongly.

In a long sprint, this will usually average out somehow; one "three-day" task will take five days, another "three-day" task will take one day. In a short spring, things are less predictable.

(yeah, technically it's not days, it's story points, but the idea is still that "medium complexity" only means "medium complexity unless something unexpected happens" and the unexpected things sometimes do happen, you can't simply commit to unexpected things never happening.)

[giulianob]

Estimating a single task is only really important to keep your cycle time in check and have the conversation about "should this task be broken down?"

Estimations from engineers shouldn't be used to forecast when a feature will really be done. That's where the model comes in and probabilities comes in.