Estimating stories in days has always been notoriously inaccurate.
So agile invented estimating stories in “points” and everyone gave a sigh of relief.
Except there were two big problems…
Problem #1: Urgency
In an ideal world, no work is urgent.
In the real world, plenty of work is urgent. On our team, for example, Coronavirus has meant a lot of urgent changes to our health product.
For urgent (and semi-urgent) work, absolute time matters. We recently had a “2 point” story that was urgent. Does 2 points mean 1 day or 4 days? What if turns out to be a “3 point” story… is that 6 days?
For urgent work, that extreme lack of precision makes life very difficult for the product manager.
Problem #2: The head in the sand
The fact is that estimating is hard. Estimating in days is certainly hard.
Estimating in points seems easy but it’s actually even harder. It’s easy to estimate in story points and not realise that your estimates are wildly inaccurate.
For estimates in points to be meaningful…
1. You need feedback on how accurate your estimates are. For our team, i plotted a scattergraph of points vs elapsed time. The trendline showed that on average, 1 point takes two days. It also showed which estimates were far from the trendline.
2. When you estimate, you need a baseline. That way everyone knows what 1 point is. Otherwise everyone is estimating in different units. On our team, for example, i’m pretty sure that 1 point means half a day to some people (even though i know it’s actually two days).
Conclusion
I believe it’s easier just to estimate in days. For more detail read my previous post, “The Inventor Of Story Points Apologises For It”.