Which comes first, story point estimation or breaking the user stories into tasks? Normally teams come up with the story points first, followed by tasking the user stories. But I would suggest working the other way around, because of the following:
It helps to know how much to commit to before committing work for the sprint.
Teams considering historical velocity for planning sprints may face a problem while committing for the sprint in case the story points of current-sprint user stories match their velocity, but the hours required to complete the user stories are more than the capacity.
I want to explain this with the following example:
"Team A" has a historical velocity of 25 story points. In the current sprint, they have identified five user stories, the sum of which is also 25 story points. As the historical velocity matches with the user stories that are in the current sprint, the team commits to all five user stories.
At the time of breaking these stories into tasks, however, the team finds that they need 400 hours to complete all the committed user stories -- but they have only 300 hours. In this scenario, what can the team do?
The only solution I see is to reduce the scope from the scope already committed.
At the end of the day, it's the availability of hours that matters. So the user stories that the team commits to should be based on hours rather than story points.
The other accrued benefit is:
While tasking the user stories, teams get to know lot of things about each user story that they would not have been aware of if they had estimated the story points first, which means that the accuracy of the story point estimation increases.
If the team first breaks stories into tasks, then follows that with story point estimation, they know how much to commit to before committing -- and the accuracy of the story point estimation also increases.