This is the case:
A problem: - The project manager wants to know when the project will be finished. We have the US stacked in the product backlog and now we need to estimate them.
I want to estimate them in story points and to track the team's performance throughout the sprints and then we can have a clear picture when the team will finish to project.
The project manager wants to estimate in days/hours these US. I believe that's not a good idea.
The project manager wants to know when the project will be finished. We have the user stories stacked in the product backlog and now we need to estimate them.
The project is going to be finished when one of two things happens. One, all of the work is finished and there's nothing else left in the Product Backlog. Two, based on demonstration and/or delivery of working software, doing more work will not add sufficient value to warrant the cost of executing another Sprint.
Using Story Points and Velocity is not for management to plan on when a project is going to be done. They aren't for anyone outside of the team. These concepts exist to help a team plan their next Sprint, to provide a reasonable sanity check that they are forecasting the completion of an appropriate amount of work and committing to an appropriate Sprint Goal. They aren't good or useful for long term forecasting - maybe you can get out as far as an extra Sprint or two. This is because they are highly unstable - as the team gets better, the baseline for a Story Point will change and evolve. It's why you can't even look back on more than a few Sprints to compute Velocity.
My advice is to not try to mix Agile Software Development and traditional project management methodologies. Embrace empiricism, adaptability, flexibility, and the responsiveness to a changing environment. Focus on value delivery and knowing when the costs will exceed the potential remaining value.
Even at the point where you are now at (product backlog is filled, team is assembled, but no sprint has been conducted so far), you can give some indication of how long the project will take to complete, under the assumption that there will be no changes to the backlog.
Based on the lowest, highest and average 'estimated velocity', you can calculate an interval for how many sprints it would take to finish the complete backlog.
For example, if you have 1000 points on the backlog and can burn between 50 and 100 points each sprint, with an average of 80 points, then the estimated duration would be between 10 and 20 sprints with 13 sprint being the most likely.
You present this interval to the project manager as
Based on our current understanding of the project, our estimations of the work and the assumption that there will be no changes to the backlog, we think the project will take between X and Y sprints, with the most likely outcome at Z sprints. After we have complete a couple of sprints, the results may change.
By presenting an interval for the estimated project duration, you are giving a clear signal how much uncertainty there is in when the project will finish. Stating your assumptions (especially the assumption that the backlog won't change, which everybody with some sense should know will be invalidated) also helps there.
Developing a software or managing a project -- name it as you want -- is in the end only a collective endeavour to transform uncertainty into a certainty:
We all have to cope with this uncertainty. Different people do it in a different way. There's no bad or good: it all depends on one own's experience and practice.
If you're more comfortable with story points, stick to your approach. Don't try to adopt a different way of thinking if your current mental model works well. Working with ideal days or even real days would require a very different mind-set.
With a team estimating the story points and a history of velocity, you'll usually get a reliable base to predict future outcomes. To transform story points in duration. Nevertheless, it's only a probable estimate based on averages and collective experience. It's not a cristal bowl either.
In your specific case, you have a new team and no velocity history.
But you have your personal experience:
Fortunately, you're not alone either. Every team member has his/her own experience both in story point estimate and velocity and comparing previous team with today's team. So you can make this a collective exercise: after having "calibrated" the team with story-pointing the stories, try to collectively assess the velocity that you can hope for. Maybe not a single number but a range in order to keep in mind that it's only an estimate.
Based on this you can make a first guess: take the total number of story points, divide by velocity. Use the number of sprints (or better the range) and add a couple of iterations to cope with missing stories that you'll inevitably discover. And here you have a first time horizon to discuss with your project manager. It's a team duration. You can convert it in workload, by multiplying by 6 and number of work hours per work day.
In every interaction related to the predicted time horizon, always recall your assumptions (i.e. no significant increase in stories) and remind the potential unreliability of the exercise. You should also insist that you do not firmly commit to these numbers but that you propose to reevaluate your prediction once you have some more reliable velocity figures.