PTO, on-call, and meetings: what's really left of your sprint
If you plan a 10-day cycle for 6 engineers, it looks like 60 engineer-days on the board. It isn't.
Here's what's actually left after you subtract what teams consistently forget.
The subtractions nobody does on the whiteboard
PTO
Almost every cycle has someone out. Teams that don't check calendars at planning systematically over-commit. A person gone for 3 days = 30% of their cycle gone. Across a 6-person team, typical PTO runs 3–5 engineer-days per cycle. That's a full person-week you didn't subtract.
On-call
On-call doesn't stop delivery entirely, but in practice the primary loses 30–50% of their cycle to interrupts and response work. Secondary loses maybe 10%. If you don't subtract this, your on-call engineer looks chronically underproductive. They aren't — they're doing the work no one else sees.
Interviews
Phone screens, on-sites, debriefs, hiring syncs. A hiring-active team can lose 5–10 hours per interviewer per cycle. Teams at peak hiring sometimes lose 20%+ of senior capacity to interviews alone.
Recurring meetings
Standup, 1:1s, team meetings, eng all-hands, product sync. A conservative 5 hours/week per person = 10 hours/cycle per person = more than a full day of delivery time.
Code review
Not a meeting, but real time. Teams doing proper review lose 1–2 hours per engineer per day. Nobody accounts for it in planning.
Support and escalations
If your team covers any production alerts, customer escalations, or cross-team questions, someone is always getting pulled. Budget for it or pretend it's free.
Rough math: 6 engineers, 2-week cycle
| Item | Subtraction |
|---|---|
| Naive capacity | 60 engineer-days |
| PTO (typical) | −4 |
| On-call (1 person, full cycle) | −4 |
| Interviews (hiring active) | −3 |
| Recurring meetings | −6 |
| Review + support + switching tax | ~−10 (or fold into a focus factor) |
| Realistic delivery capacity | ~33 engineer-days |
About 55% of naive. It tracks with what most teams actually deliver, though almost none of them plan to that number.
What to do about it
1. Make invisible work visible. Create issues in Linear for on-call, interviews, and meeting-heavy days. Assign them. Estimate them. They count against capacity.
2. Use availability data at planning time. If you have a way to mark per-person availability — full days, half days, days off — do it before you pull issues into the cycle. If you don't, ask each person "how many days can you commit" and write it down.
3. Apply a focus factor. If your team historically delivers 60% of naive, plan to 60%. Don't argue with the math. The first cycle you plan honestly will feel like you're under-committing. You aren't — you're finally committing to reality.
4. Track committed vs delivered. After a few cycles, your focus factor stops being a guess and becomes a calibration. That's the endgame.
The uncomfortable conversation
Planning to real capacity means committing to less. That's a harder conversation with leadership than committing to more and missing. But "committed to 40, delivered 30" produces the same output as "committed to 30, delivered 30" — with worse trust.
The teams that deliver predictably aren't faster. They're honest about subtraction.