Capacity Planning: How to Account for "the Real World" in Your Velocity
Theoretical velocity and real-world capacity are rarely the same number. Discover how to build a capacity planning practice that accounts for leave, meetings, interruptions, and the human variability that project plans routinely ignore.
The Velocity Illusion
Every experienced Scrum Master has seen it: a team with an average velocity of 40 story points plans a sprint for 40 points. A week in, they're behind. End of sprint, they delivered 28. The post-mortem reveals that two team members were out for medical appointments, one was pulled into an unplanned support escalation, another spent three days debugging a production incident, and the sprint contained a holiday that nobody accounted for.
Velocity is an average calculated from historical sprints. It is not a guarantee, a commitment mechanism, or a representation of any individual sprint's actual capacity. Using raw velocity as the sole input to sprint planning is one of the most consistent sources of over-commitment in Scrum teams — and it's almost entirely preventable.
Understanding the Difference Between Velocity and Capacity
**Velocity** is what the team has delivered historically, expressed in story points per sprint. It captures the team's delivery rate under whatever conditions existed during those historical sprints — including some good sprints and some bad ones, some full sprints and some disrupted ones.
**Capacity** is what the team can realistically deliver in the specific upcoming sprint, given actual team availability, known commitments, and anticipated interruptions.
These are related but distinct. Capacity is the primary input to sprint planning; historical velocity is the calibration data that helps translate capacity into a meaningful story point target.
The Components of Real-World Capacity
Team Availability
The most straightforward capacity variable is who will be present during the sprint. For each team member, calculate their available working days: total sprint working days minus planned leave, company holidays, travel days, and any part-time commitments.
Many teams express this as a percentage: if a two-week sprint has 10 working days and a developer has 2 days of vacation, their availability is 80%. Summing availability percentages across the team and comparing to a "full team" baseline gives you a sprint capacity factor.
If your team's average velocity in fully-staffed sprints is 40 points, and the team is at 75% availability for the upcoming sprint, the adjusted capacity target is approximately 30 points. This simple calculation prevents a significant proportion of sprint over-commitments.
Meeting and Ceremony Overhead
Sprint ceremonies consume real capacity. Two-week sprints typically include:
- Sprint planning: 2–4 hours - Daily standups: ~30 minutes × 10 days = 5 hours - Sprint review: 1–2 hours - Retrospective: 1–1.5 hours - Backlog refinement: 2–4 hours
Total ceremony overhead: 11–16 hours per team member per sprint, or roughly 1.5–2 days' worth of development time. This is legitimate, valuable time — but it's not development time. Teams that don't account for ceremony overhead consistently overestimate available development capacity.
Add recurring non-Scrum meetings: architecture reviews, 1:1s, stakeholder syncs, incident reviews. The cumulative overhead often surprises teams when they add it up honestly for the first time.
Support and Interrupt Work
Most development teams carry some level of ongoing support responsibility — production incidents, bug triage, customer escalations, and internal technical support. This interrupt-driven work is real capacity consumption that doesn't appear in the sprint backlog.
Track interrupt work for 3–5 sprints to establish a realistic interrupt rate. If the team averages 6 hours per developer per sprint on interrupt work, reserve that capacity in sprint planning rather than treating it as available development time.
Teams with high interrupt rates should also evaluate whether the interrupt volume is a symptom of a larger problem — technical debt, insufficient automated testing, unclear support escalation processes — that warrants dedicated sprint investment.
Onboarding and Context Switching
New team members are a positive development that nonetheless consumes capacity. An engineer in their first month on a new codebase may deliver at 30–50% of their eventual velocity due to ramp-up overhead and the learning curve of new tools, processes, and systems.
Context switching — when team members work on multiple concurrent streams — also reduces effective capacity. Research on knowledge workers consistently shows that context switching consumes 20–40% of effective working time. Teams that are pulled across multiple parallel initiatives should reflect this cost in their capacity calculations.
Building a Capacity Planning Template
A sprint capacity calculation doesn't need to be complex. A simple team spreadsheet that tracks:
1. Team member list with availability percentage for the sprint 2. Estimated ceremony time (standard plus any exceptional meetings) 3. Estimated interrupt buffer (based on historical average) 4. Calculated development capacity in hours or days
From that development capacity, apply the team's historical conversion rate (story points delivered per developer-day) to arrive at a sprint story point target.
This takes 15 minutes in sprint planning and immediately reduces over-commitment. Teams that use it report that it also creates more honest conversations about workload, since the capacity constraints are visible to everyone rather than hidden in an abstract velocity number.
Using the Data to Improve
Capacity planning data creates a virtuous feedback loop when tracked over time. When actual sprint delivery consistently falls below the capacity-adjusted target, it's a signal that one of the capacity inputs is underestimated — interrupt rates are higher than believed, ceremony overhead is being undercounted, or the story point conversion rate needs recalibration.
This feedback distinguishes between the two main types of sprint shortfall: those caused by poor estimation (stories were harder than expected) and those caused by poor capacity planning (less time was available than planned). Each has a different remedy, and conflating them produces the wrong fix.
The goal of capacity planning is not to eliminate sprint variability — variability is inherent in knowledge work. The goal is to make commitments that are honest about what the team can realistically achieve, and to build the delivery track record that creates organizational trust.
Ready to put this into practice?
Join a SAFe certification course and master agile at scale.
Browse Courses →
