Accounting for meetings, on-call, and review time when computing real sprint capacity, why historical velocity beats theoretical 100%-of-hours math, and deliberately building in slack so the team isn't structurally over-committed.
Published September 23, 2026
NAIVE capacity: 5 engineers × 40 hours = 200 "available" hours per week
REALISTIC capacity: subtract meetings (standups, planning, 1:1s — often 5-8
hours/week per person), on-call rotation (an on-call engineer's effective
coding capacity drops significantly that week), and code review time
(reviewing OTHERS' work is real, necessary time that isn't the reviewer's
own feature output)
-> actual available "heads-down" capacity is often 60-70% of the naive number,
sometimes less
Treating a 40-hour week as 40 hours of available FEATURE capacity is a reliable, common source of chronically over-committed sprints — meetings, on-call responsibilities, and code review time (Volunteer for PR Reviews' time investment, made concrete here) are all real, necessary work that isn't reflected in a naive hours-available calculation. A capacity plan that ignores these isn't optimistic, it's simply wrong, and the team pays for that wrongness every sprint via missed commitments.
Theoretical: "we SHOULD be able to complete 50 points this sprint" (a calculation)
Historical: "we've actually completed 32-38 points over each of the last 6
sprints" (an OBSERVATION)
A team's actual observed VELOCITY (story points completed per sprint, averaged over several recent sprints — directly connecting to Estimation Techniques' points-vs-hours discussion) is a far more reliable capacity signal than any theoretical calculation, because it already implicitly captures every real-world factor (actual meeting load, actual interruption rate, actual review burden) that a bottom-up hours calculation tends to systematically underestimate. Planning against historical velocity, rather than theoretical capacity, is the practical, humble acknowledgment that the team's actual demonstrated throughput is more trustworthy than any calculation of what SHOULD be possible.
A sprint planned at exactly 100% of even historical velocity leaves zero room for the inevitable — an unplanned production incident, a sick day, a task that turns out harder than estimated. Deliberately planning to SOME percentage below full observed capacity (commonly 80-90%, tuned to how volatile a given team's actual work tends to be) isn't pessimism, it's realistic accounting for genuine, recurring variance — a team that's structurally over-committed every single sprint (planning at 100%+ of capacity repeatedly) isn't actually more productive than one with deliberate slack; it just accumulates a visible pattern of missed commitments and the trust erosion that comes with it.
Q: How would you calculate capacity for a sprint where a team member is on vacation for part of it? A: Prorate their available capacity for that sprint specifically (e.g. 3 of 5 days present → roughly 60% of their normal individual contribution) rather than either ignoring the absence or treating the whole sprint's capacity as reduced uniformly across everyone — this is a straightforward extension of the same realistic-accounting principle, applied per-person rather than only at the team level.
Q: Does historical velocity account for a team that's actively improving (getting genuinely faster over time)? A: Using a ROLLING average (the last 4-6 sprints, not the team's all-time average) naturally captures recent improvement (or regression) better than a long-run average that's slow to reflect real change — this is the same kind of recency-weighting consideration that shows up in Metrics & Monitoring's tuning of alert-evaluation windows.
Q: Is deliberately under-committing (heavy slack) ever itself a problem? A: Yes — slack so generous that the team is routinely finishing far under capacity wastes real throughput and can itself erode stakeholder trust in estimates (seen as sandbagging); the right amount of slack is tuned to the team's actual observed VARIANCE, not maximized indefinitely — a volatile team needs more slack than a highly predictable one.
Q: How does capacity planning interact with Handling Scope Creep? A: Directly — a credible, quantified pushback on scope creep ('adding this displaces X') is only possible if capacity was planned realistically in the first place; a sprint planned against naive, over-optimistic capacity has no real slack to point to, making every scope-creep conversation harder and less grounded in actual, honest numbers.