Why use hours vs story points when estimating software?

On the surface, story points seem great and make a lot of sense. They provide software teams with the ability to make story estimations relative to each other, without considering time. This allows velocity to be measured. What could be wrong with that?

[carlomontoya]

We use story points, but management does sometimes ask how long strategic projects would take. So, we go back to the dev and tester(s) assigned to estimate in hours. While reading the article, I'm now thinking whether story points estimation still makes sense.

[akummboni]

After all the reading I have done, I came to this conclusion
Story Points is a measure of complexity as well as business value. It will help us to prioritize User stories, given that our whole objective is to deliver value. It is assigned to user stories
Tasks on the other hand is the work required to complete a user story. It is broken down into hours for the sake of capacity estimation in resource allocation.
I will update this comment as time goes on

[bhupan]

Hours, due to management asks us in estimate days or hours. It is tough to calculate a 15min, 30min task in story point.

[bitcoder]

I define a story base and use it as a unit of reference for determining other stories. But it requires some knowledge about the complexity of the tasks in question to determine a real story points value. When it becomes to new or unknown tasks for the team. Then we create a consensus to vote over the number of story points a task might have.

[hinchan]

boss will ask why we spend 5 calender days to finish a 2MD work but the boss doesnt know how to ask why we spend 5 calender days to finish a 2 story points task ..lol

[yodasoja]

Humans are literally terrible at absolute estimation. We have proven time and again that we are far better at relative estimation.