[Magmalgebra]

> is in points not days

I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing.

I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.

[crazygringo]

> I've never met someone for whom points didn't eventually turn into a measurement of time

The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to.

The point is that points avoid a false sense of precision: https://news.ycombinator.com/item?id=46748310

The process is quite easy to implement. And it does wind up with extraordinary efficacy gains on a lot of teams, that's the whole reason why it's so popular. But you do have to actually learn about it. Here:

https://www.atlassian.com/agile/project-management/estimatio...

[mitthrowaway2]

If it works for you, then it's a good method, but in my opinion the most transparent way to avoid a false sense of precision for time estimation (as with all else) is by explicitly including error bars, rather than changing the units-of-measure.

[Magmalgebra]

> The process is quite easy to implement

Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain. My experience is that incentives to corrupt the point system are too high for organizations to resist.

Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing had become "utterly dishonest and a complete waste of time". I respect that opinion.

If you have citations on pointing being effective I'd be very interested. I consider myself reasonably up to date on SWE productivity literature and am not aware of any evidence to that point - I have yet to see it.