Although the vast majority of Agile teams estimate stories in story points (and tasks in hours) I wave the flag for hours instead. No points, just hours… or possibly days if your stories tend to be larger.
I do understand the argument for story points. It emphasises that we are estimating size, not duration. It depersonalises estimation, particularly when dealing with non-technical stakeholders. If something is estimated as “10 hours” a stakeholder can get very difficult if it starts going into a third day.
Dealing with hours is therefore more difficult. But I like it because of the honesty it forces out. It forces us to understand what “estimate” really means. In particular, it forces our non-technical stakeholders to understand that, and therefore understand better what it means to develop software. I find it odd when I hear marketing and financial people talk about “story points”. Simon Baker has said that he’s “never met a customer who liked them”. It seems we have forced some kind of weird made-up language on them, forced them to become like us, in order to cover up a nasty truth about our work. I’d much rather we technologists thought more like the stakeholders, and turned our language towards them.
My colleague Dave Putman commented to me that it was a question of “maturity” whether a business representative can work constructively with hours. It’s true that not everyone can manage that, and it does take time. If at all possible I prefer to help those people understand and work with the nature of software development.