When I inherited the current Scrum Team I am working with the previous ScrumMaster had produced a points to hours conversion chart which allowed the team to estimate in points and the business to track estimates in hours.
Unfortunately that approach is the worst of both worlds. You do not have the flexibility of relative story points and you have extremely innaccurate estimations based on the Fibonnaci sequence.
We moved to estimating User Stories in hours which would be my recommendation for your team as well, supported by the arguments of Mike Cohn of Mountain Goat Software.
I don't use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term. It would be appropriate for a team to say “We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, “We have an average velocity of 20 story points so we will finish in the next sprint.” It doesn't work that way. Suppose a basketball team is in the middle of their season. They've scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.” This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.
Chia Cheng of the Scrum Alliance also argues that Sprint Planning should be accomplished in hours rather than points.
The task-hour estimation, on the other hand, is a low-level estimation made to represent the actual effort in hours needed to accomplish all the requirements of a story. Such an estimation should be done during sprint planning for highest possible accuracy, as the actual development may start the next day. - See more at: https://www.scrumalliance.org/community/articles/2012/august/story-points-versus-task-hours#sthash.aJgABGA6.dpuf
How we operate
Our Sprint Planning agenda includes the following capacity analysis
- Calculate the working days in the Sprint Timebox (minus planning and review)
- Annotate each Scrum Team Member on the Calendar unless absent
- Each Scrum Team member has a theoretical 8 hours
- Calculate the capacity of the team for the month in hours
- Remove 20% of the capacity for standard industry productivity overhead
The remainder will give you a fairly accurate figure of total development time available to the Scrum team. Let's use a theoretical example.
- Sprint is 10 days
- 1 day is removed for Planning
- 1 day is removed for Review, Retrospective and mandatory business employment meetings
- 8 working days remain
- Scrum Team is six strong and highly cross functional (no bottlenecks)
- Team Member A is absent for 2 days
- Team Member B is absent for 1 day
- 6 Team Members x 8 days (48) - 3 days = 45 days of total development time
- 360 hours minus 20% productivity overhead = 288 hours of development time in reality
We can then introduce the Product Owner and the User Stories to the capacity that we have available whilst always keeping 30% in reserve. We would in this instance commit to approximately 200 hours worth of user stories.
During each working day we maintain a close eye upon the Story estimates versus the actuals to ensure that what we committed to was accurate. If our capacity remains unused near the end of the Sprint we hold a quick Product Owner update to pull a sheaf of user stories from the Product Backlog to plan and start.