Velocity (not so) simple value

As defined in Scrum, velocity is simple and easily understandable value. Velocity is number of story points team is able to implement during one sprint. What is important to notice, velocity is value expressing only completely implemented user stories or features. User stories that are implemented only partially cannot be part of the velocity because Scrum recognizes only implemented and unimplemented features. So it is really easy. To calculate your velocity you should only sum story points of fully implemented user stories. And this works perfectly for the one sprint. And the next logical step is to use velocity from previous sprint as orientation point for velocity in the next sprint.

And here we come to "not so simple" part. Sprint as per definition is always of the same length. But what often differs is effort expressed in number of working days included within sprint. In the next sprint you may have bank holiday(s), somebody can have vacation, even you can have different number of team members or any other imaginable situation can change effort that will be part of the sprint. This means that effort included within the new sprint will be probably different than effort included in the previous sprint. And therefore you are not able to simply apply velocity from previous sprint(s) for the new one.

Solution to this problem is more or less simple and mainly is described in "Scrum and XP from the Trenches". You should record effort expressed as person days within sprint. One person day is one person day work on the project. So if 5 persons is working in the sprint that lasts for 2 working weeks (10 working days), effort expressed in person days is 50 person days. If one person had vacation 1 day long, effort within sprint is 49 person days. I believe it is clear enough how to calculate number of person days included within sprint.

When effort in sprint is expressed in person days, you have knowledge with what person days effort you are able to implement how many story points. Be aware that this maths will work only if you don't have big turbulences within team. If you are changing team for each sprint, then you actually don't have Scrum and therefor velocity as defined in Scrum is useless for you.

So what is the math. Let make an example.
(PD - person day, SP - story point).

Let say that for finished sprint 1 of 2 working weeks length we have following information:
Sprint 1: 50 PDs within sprint, 35 SPs implemented. This means that for 50 PDs our velocity is 35 SPs.

Let say that we know that in sprint 2 of 2 working weeks length we will have only 37 PDs (due the vacation and bank holidays). So what number of SPs we can expect to be implemented based on velocity from the sprint 1?
Equation is simple:
35SP : 50PD = xSP : 37 PD => x = (35 * 37) / 50 => 26 SP

So, for the sprint with effort of 37 PDs we can expect to implement user stories valuable of 26 SPs.

This equation should work in the most of the reasonable situations. At least that is my experience. But of course there are limitations. If you are changing the team too often, if you are changing technology, if you are changing the length of the sprint this equation will not work because all these situations changes preconditions used in the previous sprint(s).