Our world is full of uncertainty.
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:
- Starting uncertainty: can be about told and yet untold expectations/desires, about team dynamics and abilities, about customer interactions, about technical challenges, about time needed, and so on.
- Ending certainty: is a happy user in front of a (hopefully) great product). Although this end can be the start of the next episode.
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.
Stick to your own way
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.
Your specific challenge
In your specific case, you have a new team and no velocity history.
But you have your personal experience:
- If you have seen hundreds of stories estimated in your previous team, you can correlate the story points of your new team with the average story points you were used to in the past.
- You have no velocity, so you have no other choice than comparing the velocity you could expect from the new team to the average velocity you've experience in the past. This is the tricky point because you don't know how the team dynamics will work out and the size and skills could be different. But have a try and do not be too optimistic.
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.
Never disclose predictions without the assumptions
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.
