Calculate available team capacity in hours after accounting for meetings, PTO, and non-coding overhead for sprint planning.
Team capacity is the actual number of productive development hours available in a sprint. The gap between theoretical capacity (team size × hours per day × days) and actual capacity is often 30–50%, consumed by meetings, PTO, overhead, on-call duties, and context switching.
This calculator helps scrum masters and team leads compute realistic capacity by subtracting all non-coding commitments. Accurate capacity planning prevents over-commitment — the primary cause of incomplete sprints and declining team morale.
Understanding your team's true capacity helps you commit to an achievable sprint scope. Over-committing by even 10–15% consistently leads to accumulating unfinished work, quality shortcuts, and eventual burnout. Planning to 80% of capacity leaves room for unexpected issues.
Understanding this metric in precise terms allows technology leaders to make evidence-based decisions about scaling, architecture, and infrastructure investment priorities for their organizations. Tracking this metric consistently enables technology teams to identify system performance trends and address potential issues before they impact end users or business operations.
Most teams over-commit because they don't account for non-coding time. This calculator reveals the gap between theoretical and actual capacity, leading to more realistic sprint commitments and healthier teams. Regular monitoring of this value helps DevOps teams detect anomalies early and maintain the system reliability and performance that users and business stakeholders expect.
Theoretical Capacity = members × hours_per_day × days Available = Theoretical × (1 − meetings% − PTO%) Utilization = Available / Theoretical × 100
Result: 225 available hours (75% utilization)
Theoretical: 5 × 6 × 10 = 300 hours. Meetings consume 15% (45 hours) and PTO 10% (30 hours). Available: 300 × 0.75 = 225 hours of coding time for sprint commitments.
Most teams plan as if 100% of calendar time is available for coding. In reality, meetings, code reviews, email, Slack, and context switching consume 30–50% of the day. Acknowledging this gap is the foundation of realistic sprint planning.
Start with total available hours, subtract known commitments (recurring meetings, on-call, PTO), then apply a buffer for unplanned work. The result is your plannable capacity. Track actual velocity against planned capacity to refine the model over time.
The most effective capacity improvement is protecting uninterrupted focus blocks. A developer with 4 hours of uninterrupted coding time produces more than one with 6 fragmented hours. Consider meeting-free days or focus time blocks for the team.
Research consistently shows 5–6 hours of deep, focused coding work per 8-hour day. The remaining time goes to communication, email, breaks, and context switching. Some studies suggest 4 hours for roles with heavy meeting loads.
Average developer meeting load is 10–20% but can reach 30%+ for senior engineers and tech leads. Audit actual calendar time to get your real number. Aim for under 15% to maintain high coding productivity.
Only if they also contribute code. A dedicated scrum master who doesn't write code should not be counted in development capacity. Part-time scrum masters should be counted at their reduced coding allocation.
Average PTO rates are 5–10% per sprint when averaged over the year. Specific sprints may have higher rates during holidays. Always check for planned PTO during sprint planning to adjust capacity accurately.
Reserve 10–20% of capacity for unplanned work (bugs, support, escalations). Teams that don't buffer for this consistently fail to complete planned work. Track the ratio of planned vs. unplanned work to calibrate.
Expect 50% capacity for the first sprint, 75% for the second, and full capacity by the third sprint. Additionally, existing team members lose 10–15% capacity per new member for mentoring and code reviews.