Sprint planning and Vacation

The first thing is to recognize that story points are never delivered. The concept is ridiculous, and I suggest you find out how it has found its way in. Value is delivered. The purpose of story points is to help teams figure out how much work they can take on in a Sprint. If they anticipate that they need to take on less because of upcoming vacation, then indeed perhaps that's what they should do.

If you think about it in terms of the team's capacity to do work, it makes sense to reduce the amount of work planned for a Sprint. If you know in advance that one or more members of the team will be unavailable, you should consider that reduction when planning the Sprint.

As far as calculations go, I tend to work in hours. If you know the number of hours (approximately) the team worked to achieve 30 story points, you can establish a new maximum based on the vacation. For example, if you have a team of 4 Developers working a standard (in the US, anyway) full-time role at 40 hours/week and are using 2 week Sprints, you have 640 hours in the Sprint. If one Developer is taking one full week off, you are reduced to 600 hours. If you completed 30 points in 640 hours, you are likely to complete no more than 28 story points and probably less than that as the Developer will need some catch-up time when they return. Based on my experience, I'd encourage the team to take a look at the Sprint Goal and the associated work and check that the work associated with completing the Sprint Goal is estimated at about 20 points and plan on no more than 25 points for the whole Sprint. It is a bit naive in that it assumes that people are equal in both knowledge and contributions, but it is fast and easy to do at Sprint Planning. Nothing can beat the team's check of the work against what they believe they can do.

Velocity is the average amount of work (story points) turned into a done, usable increment during a Sprint. Velocity is usually averaged out over a few Sprints and is used to forecast Sprints, Releases and Budgets. Velocity is not a desire or an edict, its a result. Regardless of your teams Velocity, its meant to be used as a guide during Sprint Planning. Before your Sprint Planning Event ends, the team should agree whether they have too much, too little or the right amount of work. Your Velocity may be 30 and the team may feel like 25 is enough. Another time, they may feel like 35 feels like the right amount. Ultimately, the Developers need to forecast the amount of work they think they can complete in the Sprint.