Estimate your team's capacity as an aggregate range based on historical performance, rather than as a sum of the ideal hours available to each individual. Furthermore, you should carefully consider what you hope to accomplish with such a calculation, and determine whether a more agile approach to productivity and statistical estimation might not be a better fit.
Estimate Team Capacity
My team works in a 3 Weeks sprint, and accordingly we calculate the capacity of Team member based on his or her planned holidays and company Vacations.
In Scrum, velocity or capacity for an individual is never calculated. Instead, you calculate the projected capacity of the entire team based on empirical measures of past performance, and expect minor variations in individual or iteration capacity to even out over time.
More importantly, while you can use various techniques to estimate ideal hours available to the team, this will not give you good predictability regarding the amount of work you can do in a Sprint. Unless it's your very first Sprint, you're much better off using relative sizing (e.g. story points) and estimating how much work you'll be able to accomplish in any given iteration based on empirical data about how much work the team has been able to accomplish in the past.
Even if you choose to use ideal hours rather than story points, you would calculate a team capacity. For example:
- Make sure you include all elements of your Definition of Done in your definition of work.
- Assume a baseline of 4-6 hours of useful work per business day.
- Multiply by the number of team members.
So, a five-person team has 60-90 ideal man-hours available in a three-week Sprint. You could just stop there, and let statistical variation iron itself out.
As an alternative, you can apply a fudge factor to adjust for known issues in a forthcoming Sprint. For example, you might:
- Reduce total capacity by at least 20% if a member of a five-person team is on extended leave.
- Reduce capacity by 7-10% to account for a holiday in the middle of your upcoming Sprint.
Pragmatically, I tend to apply fudge factors for large potential drags on velocity, but generally ignore them for minor perturbations like a planned dentist appointments.
Solving Your X/Y Problem
It seems likely that your real problem isn't a lack of precision estimation, but rather than you are treating team members as individual resources and striving to optimize for utilization rather than throughput. While you didn't explicitly say so, the way your question is phrased at least implies that tasks are being assigned to individuals, rather than collectively owned by the team, and therefore the absence or reduced capacity of any member of the team can create bottlenecks or expose dependencies within your delivery pipeline.
Don't do that.
Instead, make sure that backlog items are owned by the entire team, and that the team is working collaboratively to complete stories rather than sequentially or in parallel. In addition, backlog items should be as independent of one another as possible, so that the inability to complete one due to resource or time constraints doesn't "halt the line" for other backlog items as well.
Even if you're not making the mistakes I just outlined, please take some time to really consider why you are trying to trace capacity metrics to the individual level, rather than taking the team-based approach that underpins most agile methodologies. You may be surprised to find that doing so is unnecessary, and even counterproductive, in many circumstances.