2 ms·
> Estimates also need to capture the level of uncertainty. As a junior developer, I was asked to provide LOEs for tickets and tasks. I just looked at my boss.
by eropple 6y ago
> Estimates also need to capture the level of uncertainty.
As a junior developer, I was asked to provide LOEs for tickets and tasks. I just looked at my boss. "How should I know?"
"Come up with your best answer." So I did. I gave him my best guess, plus some error bars. The error bars were promptly discarded. And while when I went over estimates I didn't feel bad, there was obviously some static there from my boss when things went "over estimate".
I have harbored a lot of suspicion towards the process of ticket estimation and "story pointing" and the like ever since.
- lliamander 6y agoA manager who cannot deal in error bars is not doing their job correctly, although I would also point out that it is important to re-estimate and update your boss as soon as you think you will miss the estimate (which you may have done). In my previous environment, we were only allowed to give estimates in terms of a range of time. We had a series of predefined "buckets" of time ranges (e.g. less than a day, 1-2 days, 2-3 days, 3-5 days, 1-2 weeks, 2-3 weeks, 3-6 weeks). As the estimates got bigger, so did the error bars, and if a task didn't fit comfortably into one bucket then it was upgraded to the next. We also had design discussions and poker planning for all of these tasks. Estimates were almost always accurate, even if they weren't very precise.
- eropple 6y agoI mean, I was a junior engineer. I didn't know when I was gonna miss the estimate, when you're heads-down like that you don't know if you're 25% in or 80% in until you've gotten a lot more experience. Hence the error bars in the first place. ;)