Team Capacity Calculator

About the Team Capacity Calculator

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.

When This Page Helps

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.

How to Use the Inputs

1. Enter the number of team members.
2. Enter productive hours per day (typically 6–7 of an 8-hour day).
3. Enter the number of working days in the sprint.
4. Enter the percentage of time spent in meetings.
5. Enter the percentage of PTO/absence during the sprint.
6. Review the available coding hours for sprint planning.

Example Calculation

Tips & Best Practices

• Plan sprint commitments at 80–85% of available capacity for buffer.
• Track meeting time as a percentage — many teams don't realize it's 20–30%.
• Account for on-call duties, support rotations, and unplanned interruptions.
• Use 6 productive hours per 8-hour day as a realistic baseline.
• Include onboarding time for new team members (typically 50% capacity first sprint).
• Review capacity at sprint planning, not just beginning of quarter.

The Capacity Planning Gap

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.

Building a Capacity Model

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.

Protecting Developer Focus 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.

Frequently Asked Questions

• How many productive hours are in a workday?

  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.

• What percentage should I allocate to meetings?

  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.

• Should I include the scrum master in capacity?

  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.

• How does PTO affect capacity?

  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.

• What about unplanned work?

  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.

• How do new team members affect capacity?

  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.