Velocity is not a management target. It's an estimation tool, and you should be using it as one tool among many to help plan your Sprints. Don't treat velocity metrics as targets, or maintaining a given velocity as the primary goal of each Sprint.
Hours and story points have no direct relationship to one another. Story points measure relative effort, while hours measure ideal or wall-clock time. They are both useful, but are not interchangeable.
Estimating Variable Capacity
Velocity is a range, not a single value, and is generally most useful when:
- Planning a project schedule once the velocity stabilizes.
- Applying a smoothing function to spiky per-sprint results.
However, unless you've gathered sufficient velocity data to amortize variations in capacity, then you have to apply some common sense instead. Consider these examples:
If you've been doing Scrum for a year, people take sick days, go on vacation, or work above or below their typical capacity from time to time. Velocity averages those data points over time, and allows you to make reasonable estimates anyway.
You've only been doing Scrum for two months, and have had all hands on deck for both Sprints. You have zero data regarding normal variation, and no information on maximum or minimum team capacity. You will therefore have to apply a fudge factor.
It's Okay to Under-Commit
In Scrum, the main goal of Sprint Planning is to avoid over-commitment during a Sprint. The idea isn't to fulfill the 100% utilization fallacy; you don't have to pack each Sprint to the rafters based on your previous velocity.
The way Sprint Planning works is that velocity simply offers guidance, letting you know if you've gone over the reasonable work-in-progress limits for a single Sprint. It is up to the Development Team alone to determine how many story points can comfortably fit within the current iteration.
In your example, when you will be under-staffed for a Sprint, it is expected that the team will acknowledge this fact and adapt accordingly during Sprint Planning. For example, the team might say:
We normally try to limit our story points to 10-15 points per sprint. However, Bob is out having COBOL-based cybernetic implants placed into his cerebral cortex, so we should probably only commit to 8 points or less this time around.
The team then accepts only 8 points into the Sprint, based on their expected capacity. However, if they finish early, they can (and should) go back to the Product Owner in order to:
- Gather a few more small stories to round out the Sprint without over-committing.
- Ask the Product Owner for an Early Termination so that the Sprint Review, Sprint Retrospective, and Sprint Planning can be performed without simply waiting for the clock to run out.
The first is the most common practice, but the second is certainly acceptable within the bounds of the Scrum framework. It really just depends on what works best for your team.