It’s easy to forget precisely what the purpose of point-based estimates is, often resulting in attempts to equate them to time. However, that’s not what they’re for.
Point based estimates using the Fibonacci scale, t-shirt sizes, and any other method of measuring relative complexity are tools to help the business prioritise a backlog. These finger in the air estimates are useful insofar as they can provide a crude method of deciding whether to tackle 3 simpler tasks or one more complex one in the upcoming sprint. This represents the limit of their usefulness. Beyond that these estimates hold no value, especially when attempts are made to attribute a period of time to them.
The time a story takes does not correlate to its original points value. Traditional burndowns work in the sense of points-per-sprint, however there is no remit for turning these into a real period of time–they merely highlight a teams ability to reliably compare complexity to a base-story’s estimate.
Smalls, mediums and larges will blur into each other when time is taken into consideration. Metrics off the back of finger-in-the-air estimates only compound incorrect thinking in the upper echelons of the business as to a teams ability to deliver production code.
If you need to know hours because you’ve a deadline, or you’re billing out to a client, then sprint planning is the place for estimates in half days or above. The stories you choose to plan are in the upcoming sprint because of your finger in the air point estimates, but now it’s time to get into the nitty gritty and figure out just how long this thing will take. These discussions often make stories considerably more or considerably less complex when compared to their original estimate.
In summary, if you need to know how long a story will take in hours, get your best guys to estimate in half day chunks. Don’t use points.