... your Product Backlog tracks the delivery order of value increments to the market. Sprint Planning has to accommodate vacation, pregnancy leave, anticipated medical leave, and even team outings, all of which take time away from development but which are traditionally respected by corporate human resources culture. These activities affect delivered value directly and costs indirectly. Unlike work on Product Increments, for which Product Owners can schedule the Development Team solely with respect to business considerations, vacations and other "personal" events are sometimes beyond their control (see Fixed-Date PBI). Medical leave and long-term competence development often fit in this same category.
✥ ✥ ✥
Vacation and other planned times off are technically honored under most corporate value systems, but they don't create market value in the same way that product increments do. Therefore, it is common for Project Managers who become ScrumMasters or Product Owners to view vacations and other planned off time as impediments, as contributing negative value, or at least as a "special case" that should be separated from business value considerations. For example, some teams may view vacation as a Human Resources concerns outside the scope of development scheduling. Of course, that's unrealistic from a scheduling perspective, so it becomes necessary to treat staff as a resource that is adjusted when planned absences arise. Many teams adjust their Velocity downward to compensate for anticipated absences, only to restore it on the individuals' return.
Scrum can be used to optimize any value. Hall  broadens value to encompass the economic, casuistic, and psychological theories of value. Vacation and training, as contributors to the casuistic theory of value, are usually ignored in making the Product Backlog, because it usually tracks economic items. Workers in particular respond at least as strongly to the casuistic theory of value as to monetary rewards  and, of course, the psychological theory of value is crucial in a work environment. Some of the most highly valued items on professional Scrum teams lack representation on the major organ of value.
You want the Development Team to meet its forecast regularly, and you want to the Developers to regularly stay on a Kaizen path that sees both predicability and capacity for work increase over time. The Team uses Velocity for both of these. And while Velocity is not a strict predictor either of ROI or of efficiency, it is the central empirical measure of the Developers' capacity both to predict and complete work.
Absenteeism changes the velocity. While vacation absence is a small fraction of the year in the United States, it is also the only country in the world without a single legally required paid holiday (Alexander E. M. Hess, "On holiday: Countries with the most vacation days," USA Today, 8 June 2013). Austrians take 35 paid days off each year: about 15% of the work year. If you combine these absences with conference attendance, continuing education, and other activities that don't contribute directly to the product, as much as 20% of the budget may be spent on activities that are usually accounted for only "in the margins." And during the summer or around winter holidays, the majority of the Developers may disappear together for up to a month. It's important to give visibility to how that effects deliverables.
Scrum is an empirical framework and Velocity is empirically derived according to Yesterday's Weather. A good Team tracks its Velocity over time, focusing first on reducing its variance and secondly on occasionally increasing it through Kaizen. Adjusting the Velocity downward to compensate for an absence destroys the empirical nature of Velocity leading to complex, arbitrary calculations as often found in Project Management. Scrum has no facility for "remembering" adjustments to Velocity or, and has no need to "remember" velocity: one can always derive it from empirical data. So a manual velocity adjustment would add a new Scrum artifact. Even with sophisticated adjustments, it becomes impossible for the Team to determine whether its base Velocity held on track in any Sprint whose Velocity was manually adjusted rather than empirically derived. The resulting arbitrariness of the calculated Velocity leaves Developers without any sense of responsibility to meet their forecast.
Track planned Development Team member absences as PBIs. Let the team estimate the cost of the PBI depending on the specifics of the absence and of the Sprint in which it will occur. The Product Owner may choose to ascribe a corresponding value (ROI) to the PBI as well, corresponding to the value to the enterprise of such absences.
As is true with any manipulation of the Product Backlog, the relative position of the Vacation PBI should frequently be adjusted so it occurs in the Sprint commensurate with the fixed date (see Fixed-Date PBI).
One could mechanically ascribe a cost to such PBIs based on the team size, its velocity, and the absence duration. However, Development Team performance is rarely linear in the number of available Team members. Different Team members perform differently, but more important, an effective Team works as a gestalt where Team members multiply each others' effectiveness rather than just linearly summing their contributions. This is why we let the team estimate instead of using typical Project Management formulæ. The common practice of letting the Product Owner (or even the team) adjust the velocity mechanically falls into this trap. There are further subtleties that the Team estimation can accommodate. For example, adjusting merely for the Team member's absence doesn't acknowledge the effort of re-integrating them into the team on their return: to learn how the code base, organization, market, and requirements have changed in their absence.
Given these realities, the pattern has limitations in how it affects the accuracy of the Sprint forecast. However, first: it directly supports the following Scrum principles:
Second, it is better than nothing: the situation is no better if the Product Owner or Team affect a downward Velocity adjustment for absences. In the end, the Team owns the estimates: putting the Velocity figure in the hands of someone other than a Pig takes away the Team's sense of commitment.
This pattern is of course a two-edged sword, and each culture will modulate the boundaries of application of this pattern. It's important to ponder the stipulation that the Product Owner can neither schedule nor refuse personal absences that are traditionally matters of personal employee choice and discretion. Some cultures may give Product Owners leeway in allowing or disallowing activities such as conference attendance (though vacation in particular is outside the Product Owner's purview.) We use vacation as the exemplary case in this pattern to emphasize the Scrum principles above.
Another challenge exposed by this pattern is the visibility it may be perceived to bring to the Team's assessment of individual contribution. It may insult Jim if Sue's vacation reduces velocity by 20, and reduces Jim's velocity by 30. In practice the identity of the individual isn't the only factor in sizing such cost: for example, different technology mixes in a Sprint lead to variance in the cost of different individuals' absences, as do other variations. However, in any case, the Team will realize a change in velocity during a Team member absence, and that will lead to the same issue of quantifying the value of the individual to the team. The fact is that the natural variance in Velocity is likely to overshadow variances in the identity of the person absent, and it is unlikely that there are enough data to make any statistically significant judgement about such costs. Perception is everything, however, and the ScrumMaster must educate the Team that variance in the estimation of a Vacation PBI is natural.
Some have argued that this is a complicated pattern. While the arguments are intricate, the solution is not. The traditions against such common-sense approaches are strong, which is why the forces here are sometimes hard.
These arguments and adjustments aside, the ceremonial inclusion of such absences on the Product Backlog make visible that care for the personal well-being of team members (through vacation, medical care, etc.) is indeed part of the corporate value proposition. It shows that management cares. Management sympathy or empathy has empirically been shown to increase productivity  while disdain for such personal concerns can demotivate the team or build resentment. This is all within the Scrum spirit of extending the notion of value beyond the product, into concern for the Team and its people, as exemplified in the mission statement of Toyota's Nummi plant :
Regarding transparency, the Product Backlog is an established information radiator and organ of transparency in the Scrum culture, with the expectation that its Sprints are delineated by the Team's velocity. Making extraordinary absences into PBIs takes away their extraordinariness; all necessary information is transparent. Any local adaptation of a Sprint velocity complicates the bookkeeping of velocity because it means keeping an "undo stack" of such adjustments to be processed when the absence is over.
This approach is one example of how the Product Backlog can be used to communicate broad concerns of the value system, beyond just "product" increments. Treating such absences as PBIs also makes it visible on the Product Backlog approximately when and how the absence will affect the inclusion of individual product increments in projected releases. If Sprint velocity is adjusted instead, then each Sprint has a custom velocity, and that seriously complicates the predictions provided by simple, manual tools as well as by more sophisticated computer-aided tools. These complications make the Product Backlogs unwieldy to interpret.
Note that this pattern does not apply to unplanned Sprint interruptions such as incidental sickness or unanticipated business condition changes. Those are stochastic quantities that are handled either by Drag (a drop in the real Velocity) or, in extreme cases, by Stop the Line.