The metric for estimating user stories is an interesting subject for discussion. I know that because it has been discussed a lot and not entirely without passion. There are many arguments for using man-hours or man-days.
How is this unlike making an upfront plan? The estimates are optimistic and out of the magician’s hat at best. Usually what matters is when the high level features will be completed. If the product planning has been performed with any diligence at all, the stories will be estimated in relation to each other. Even if there is undue optimism in scheduling, it is easier to compare the complexity of two stories on a rough scale. When some of the estimates have been put to test, the level of optimism can be calculated from the velocity of the team and then eliminated from the projections.
In a scaled Scrum environment it is vital that each team makes their own estimates. If a story is to allocated to another team, that team needs to re-estimate it. Because different teams have different ways of working, levels of maturity and knowledge of certain aspects of the project, the units may be considerably different. Even the perception of effective man-hours per man-day may vary. Conversions can be made for statistics but people tend to consider man-days as a promise of calendar time. From a velocity projection, it is visible which stories from the priority list will actually sink. The point is to move out from the estimated or promised values.
Estimates tend to be optimistic. The team can have high hopes of what they are able to achieve, but their history is something concrete that they cannot and should not shake off. It may be beneficial for the team to try and reach a higher level of productivity but that does not happen without learning how to estimate first. The amount of achieved story points will change quickly and dramatically. The question of how many man-days is an estimated man-day emerges. This is when it is easiest to promise to fix the correlation and the unreliability sneaks in after the next sprint. Such pressure often turns into losing the sustainable pace and suddenly the man-day is 9 hours or the previous wrongs in estimations will always leak to the next sprint.
There are many definitions of a story point. It should be something that everyone in a team can estimate. It may sound counter-intuitive for me to state that a rather good initial estimate for a story point is one day or hour of work. If there is a better common denominator, it can be used but initially a time will do. After one or two stories have been assigned an estimate, the rest will then be estimated as comparatives to the first.
The points should not be corrected back to calendar time. The problem with that approach is that it will not reveal progress. After all, the members of a team will work roughly 40 hours a week even next year. It is possible that the size of a point may change over time but so should the accuracy of estimation. The most important thing for a team is to learn to plan according to their past performance. Calling the points days or hours just helps people to jump to conclusions.