Sprint Planning Around PTO for Tech Teams
An engineering manager and scrum master guide to sprint planning that respects PTO, on-call rotations, and release windows before the team commits to the sprint.
On a Monday sprint planning call, the engineering manager has the backlog open on one screen and the PTO calendar on another. The team committed to 38 story points last sprint. This sprint feels lighter, so the product manager is pushing for 45. Halfway through the meeting somebody notices that two senior engineers are out for the entire third week, the on-call rotation lands on a tech lead who is also covering a release, and the new joiner is still ramping. By the time the team gets honest about capacity, it is closer to 28 points than 45. The product manager is frustrated. The engineers are quietly relieved.
This guide is for the engineering manager or scrum master running sprint planning for a team of 5 to 15 engineers. The thing that breaks sprint commitment is not commitment itself. It is the gap between the team's calendar capacity and the planning math. PTO, public holidays, on-call rotations, ramp-up, and meeting overhead all subtract from the 80-hour fortnight before the first ticket is sized. The fix is making that math visible before the planning call starts, not during it.
Why sprint planning is a capacity problem first
Sprint planning is often described as estimation: how many story points fit in two weeks. The estimation conversation matters, but it only works if the denominator is honest. A two-week sprint has 80 hours per engineer in theory. In practice:
- An engineer on a one-week vacation in the sprint is at 40 hours.
- An engineer on on-call rotation loses 4 to 8 hours of focused time per week.
- An engineer leading a release loses a full day for the deployment plus the post-release watch.
- An engineer ramping in her first month is realistically at 50 to 60 percent of full capacity.
- Every engineer loses 4 to 8 hours per week to standups, planning, retros, and 1:1s.
A 10-person team that looks like 800 hours on paper is closer to 550 hours after PTO, on-call, releases, ramp, and meetings. That is the number the sprint commitment has to fit inside. Pretending otherwise is how teams end the sprint with carry-over and a tired retrospective.
The PTO-aware capacity sheet
Before the planning call, the scrum master or engineering manager prepares a capacity row per engineer. The fields are simple, and they are the same every sprint:
| Field | Source | Typical impact |
|---|---|---|
| Working days in sprint | Calendar minus public holidays | 8-10 days |
| PTO days | Leave tool (BreezeLeave) | 0-5 days |
| On-call hours | On-call schedule | 4-8 hours per week on rotation |
| Release day(s) | Release calendar | 1-2 days for the release owner |
| Ramp factor | Engineer's first 60 days | 50-80% of full capacity |
| Meeting overhead | Standing meetings | 4-8 hours per week |
The total is the engineer's available hours for the sprint. The team total is the team's available hours. Convert to story points with the team's average velocity per hour, and the sprint commitment writes itself. The planning call becomes a conversation about which tickets, not how many.
Where the PTO data has to live
For the capacity sheet to be accurate, the PTO data has to be current and visible to whoever is preparing the sprint. The pattern that breaks: PTO lives in HR's spreadsheet, the engineering manager copies the next sprint's dates into Notion, and the copy goes stale the moment someone reschedules.
The pattern that works: the leave tool has an API or an export that the engineering manager pulls before each planning call, or it pushes updates into the team Slack channel so changes are visible in chat. BreezeLeave does both. The Slack vacation bot setup explains how to wire the channel summary so the engineering manager opens sprint planning with the data already in front of her.
The morning summary that prevents surprises
BreezeLeave posts a daily summary to the team Slack channel: who is off today, who is back, what is coming up in the next two weeks. By the time sprint planning starts on Monday, the manager and the team have seen the same calendar five times. Nobody is surprised by the third-week vacation.
On-call rotation and PTO
On-call rotations and PTO interact in ways that are easy to get wrong. The rotation is set weeks in advance. An engineer requests vacation that lands inside her on-call week. The rotation has to swap with another engineer, who now has two on-call weeks in a row, and is unhappy.
Two rules that prevent the rotation churn:
- PTO is allowed in on-call weeks, but the swap happens at request time. When an engineer submits a vacation request that overlaps her rotation, the approval flow includes naming the swap partner. The on-call schedule is updated at the same time as the leave is approved.
- The on-call schedule is public. Everyone on the team can see who is on rotation when, in the same calendar that shows who is on vacation when. Most teams use a shared Slack channel or a calendar view to keep both in one place.
The leave tool does not need to own the on-call rotation. It has to be visible alongside it. The cover person assignments piece covers the broader pattern of coverage at handoff.
Release windows and the freeze conversation
Most engineering teams have at least one or two release windows per year that are sensitive: a major version release, a launch tied to a marketing campaign, a year-end stability freeze. PTO during those windows is not banned, but it is worth a conversation.
The pattern that works: the release windows go on the team calendar in BreezeLeave as soft blackouts. A request that falls inside the window does not auto-deny; it routes to a second approver (the engineering manager plus the release captain) instead of the regular single approver. The blackout policy examples piece covers the spectrum from hard freeze to soft conversation. For tech teams the soft version almost always works better.
What the sprint planning call looks like after the change
Before the change, the planning call spends 15 minutes discovering that the team is short two engineers and adjusting the commitment in real time. The product manager learns the bad news in front of the whole team. Trust takes a small hit. Story points get assigned anyway, and half the sprint is spent catching up.
After the change, the engineering manager opens the call with a single slide: team capacity for the sprint, broken out per engineer with PTO and on-call already subtracted. The product manager sees the number before the discussion starts. The conversation is about which tickets to commit to, not about whether the team has time. The sprint ends with fewer carry-overs and a retrospective that focuses on engineering decisions rather than calendar math.
The Slack channel pattern
For tech teams that already live in Slack, the leave tool stops being a separate web app and becomes a Slack workflow. BreezeLeave covers the three things that matter for engineering:
- Requests submitted from Slack. An engineer types a slash command, picks dates, and the request is in front of her manager in seconds.
- Approvals from notifications. The manager taps approve or deny without leaving the channel. The balance updates and the calendar entry appears immediately.
- Daily morning summary in the team channel. The same data everyone needs for standups, sprint planning, and release decisions, in one place.
The setup is on the Slack vacation bot page and takes about five minutes for someone with workspace admin rights. Teams on Microsoft Teams get the same workflow via the Teams integration.
When the team is distributed across countries
Most modern engineering teams have at least two countries on the roster. The sprint planning math gets harder because public holidays are different per country. A US engineer has July 4. A UK engineer has bank holidays. A Croatian engineer has Statehood Day. The team's available days per sprint depend on who is in which country.
The managing PTO across countries piece covers the broader pattern. For sprint planning, the practical step is to let BreezeLeave assign holidays per engineer's country automatically. The capacity sheet then shows the right number of working days per person, with the country math handled in the tool.
The short list
A tech team has PTO-aware sprint planning when the following are true:
- The capacity sheet is prepared before each planning call, not during.
- PTO data flows from the leave tool into the capacity math automatically.
- On-call rotation conflicts are resolved at the time a request is approved.
- Release windows are visible on the team calendar as soft blackouts.
- The Slack channel shows daily who is off and what is coming up.
- Public holidays per country are applied per engineer automatically.
Hit those six and sprint planning becomes a 30-minute scoping conversation rather than a 60-minute capacity debate. To wire the calendar into Slack so the data is visible without anyone exporting it, connect BreezeLeave to Slack and configure the team channel summary. The tech companies overview covers how the features fit together for engineering teams specifically.
