[elthor89]

I dislike the story points. Maybe 5 people in the world who understand them how to use it correctly. Often, it's just translated to hours.

The scrum guide 2020 doesn't mention story points at all.

I don't know how to fix this. But maybe we should just go back to plan in hours..

[rerdavies]

I rather like the idea of "days (hours) to complete assuming nothing goes wrong". With the explicitly given understanding that we all understand that these estimates are necessarily fictional.

Pros:

- It provides a common reference for everyone in the hope that developers might at least be consistently misestimating.

- It provides an easy justification for burndown multipliers, for those external sorts of people that object to burndown multipliers. "The burndown multiplier is a calibrated measurement of how imperfect scheduling estimates are (see The Mythical Man Month). Now go away and stop imposing unnecessary drama on my development team."

- It provides cover to those who assigned initial story points from being needlessly stressed over differences between estimated and actual effort (if you have one of those dreadful people who don't get it involved in your process).

[lazycog512]

the best I've seen is just treating them as roughly day-equivalents.

the problem with pointing is that a lot of tickets are really really trivial and the main expenditure is attention, not effort. and on the other hand, the cards that are big enough to warrant measurement are often chuck full of unknown unknowns.