[netghost]

I worked on a product that was built around planning an estimation with ranged estimates (2-4h, 1-3d, etc)

2-12d conveys a very different story than 6-8d. Are the ranges precise? Nope, but they're useful in conveying uncertainty, which is something that gets dropped in any system that collapses estimates to a single point.

That said, people tend to just collapse ranges, so I guess we all lose in the end.

[crazygringo]

> 2-12d conveys a very different story than 6-8d.

In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly decide to do it or not if you had no idea if it could be 2 or 12 days. That's a big benefit of the approach, to de-risk that kind of variance up front.

[Leherenn]

> you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing

That's just too slow for business in my experience though. Rightly or wrongly, they want it now, not in a couple of sprints.

So what we do is we put both the investigation and the implementation in the same sprint, use the top of the range for the implementation, and re-evaluate things mid-sprint once the investigation is done. Of course this messes up predictability and agile people don't like it, but they don't have better ideas either on how to handle it.

Not sure if we're not enough agile or too agile for scrum.

[mitthrowaway2]

If you measure how long a hundred "3-day tasks" actually take, in practice you'll find a range that is about 2-12. The variance doesn't end up getting de-risked. And it doesn't mean the 3-day estimate was a bad guess either. The error bars just tend to be about that big.