12 ms·

I've been advocating for 3-point estimation for quite a while. [1] Unfortunately it doesn't happen very often (mainly because tooling support for this has been

by spion 3y ago

I've been advocating for 3-point estimation for quite a while. [1] Unfortunately it doesn't happen very often (mainly because tooling support for this has been missing in popular trackers such as Jira). In situations where I was the decisionmaker on the methodology I've had excellent success with it. (using about 90%-95% confidence interval was typically right on the mark) [1]: https://en.wikipedia.org/wiki/Three-point_estimation https://en.wikipedia.org/wiki/Three-point_estimation

steveBK123 3y ago
I think that's a pretty smart model - best/worst/most likely. One thing I found lacking in kabuki agile theatre was that we were ABSOLUTELY NOT supposed to "get into the weeds" in meetings where we talked estimates. But how does one uncover the best/worst/most likely without doing so? You can spend 20min writing the most beautiful Acceptance Criteria but if you don't get a bit into detail on what the user actually wants it's all for naught. It could be way simpler (hey what if I just did X) or way more complex (oh well now that you mention it..), etc. Typically it was engineering manager & engineers sitting in a room discussing requirements with each other. What could go wrong obviously? lol.
- k__ 3y ago
  Thing is, you can always put in "never" as worst case.
sanitycheck 3y ago
This is good, but I think the "most likely estimate" is going to be misleading a lot of the time. I don't have numbers to back it up, but I have a strong sense that the actual time to completion tends to be either at the quick end or the slow end of the estimation range, and only rarely somewhere in the middle. A bactrian, not a dromedary. If we hit the problems we were anticipating we might then the whole thing can take ages, but if we don't hit them it's pretty quick. Best and worst case are going to fairly predictable in advance (the latter improving a lot with experience) so I'd stick with just those personally.
magicalhippo 3y ago
I'm doing something similar I guess. It's more of a two-point plus uncertainty/confidence estimation. I'll give a range (2-3 days say) and I'll estimate how uncertain (or how confident) I am in that range. For larger tasks I'll break it down into smaller subtasks and estimate individually. For example if I need to use some new library that I've never used before, my estimate for that will be quite uncertain. Perhaps the library has some weird quirks it takes time to figure out. If I have to do something I've done often, I'm quite confident in my estimate. Effectively similar, except I don't like to estimate unknowns so I don't give an explicit worst-case time.

by spion 3y ago

steveBK123 3y ago

I think that's a pretty smart model - best/worst/most likely. One thing I found lacking in kabuki agile theatre was that we were ABSOLUTELY NOT supposed to "get into the weeds" in meetings where we talked estimates. But how does one uncover the best/worst/most likely without doing so? You can spend 20min writing the most beautiful Acceptance Criteria but if you don't get a bit into detail on what the user actually wants it's all for naught. It could be way simpler (hey what if I just did X) or way more complex (oh well now that you mention it..), etc. Typically it was engineering manager & engineers sitting in a room discussing requirements with each other. What could go wrong obviously? lol.

k__ 3y ago
Thing is, you can always put in "never" as worst case.

sanitycheck 3y ago

This is good, but I think the "most likely estimate" is going to be misleading a lot of the time. I don't have numbers to back it up, but I have a strong sense that the actual time to completion tends to be either at the quick end or the slow end of the estimation range, and only rarely somewhere in the middle. A bactrian, not a dromedary. If we hit the problems we were anticipating we might then the whole thing can take ages, but if we don't hit them it's pretty quick. Best and worst case are going to fairly predictable in advance (the latter improving a lot with experience) so I'd stick with just those personally.

magicalhippo 3y ago

I'm doing something similar I guess. It's more of a two-point plus uncertainty/confidence estimation. I'll give a range (2-3 days say) and I'll estimate how uncertain (or how confident) I am in that range. For larger tasks I'll break it down into smaller subtasks and estimate individually. For example if I need to use some new library that I've never used before, my estimate for that will be quite uncertain. Perhaps the library has some weird quirks it takes time to figure out. If I have to do something I've done often, I'm quite confident in my estimate. Effectively similar, except I don't like to estimate unknowns so I don't give an explicit worst-case time.