Team Capacity Calculator
Calculate a team's effective sprint capacity in hours from member count, hours per sprint and a realistic focus factor.
Inputs
Number of people contributing engineering work in the sprint.
Nominal working hours available per member for the sprint (e.g. 2-week sprint × 8h/day × 5 days = 80h).
Fraction of nominal hours actually available for planned work after meetings, support, interruptions and context switching (typically 0.6-0.8).
Historical average engineering hours consumed per story point, to translate capacity into a points estimate.
Effective Sprint Capacity
336.0hours
Estimated Capacity
84.0story points
Nominal Hours (before focus factor)
480hours
Hours Lost to Overhead
144.0hours
Step by step
Nominal hours: members × hours/sprint
6 × 80
= 480 hours
Effective capacity: nominal × focus factor
480 × 0.7
= 336.0 hours
Estimated capacity in points
336.0 ÷ 4
= 84.0 points
How it works
Team capacity should reflect realistic availability, not just nominal working hours: capacity = team_members × hours_per_sprint × focus_factor, where the focus factor (typically 0.6-0.8) accounts for meetings, code review, production support, context switching and other overhead that reduces time actually spent on planned sprint work. Dividing effective capacity by a historical hours-per-point rate translates raw hours into a story point budget comparable against sprint backlog estimates.
Formula
available_hours = team_members × hours_per_day × working_days × (1 - overhead_percent / 100)
- team_members
- Number of team members
- hours_per_day
- Working hours per day
- working_days
- Working days in the period
- overhead_percent
- Percent of time spent on meetings/overhead
Frequently Asked Questions
Why is focus factor typically only 0.6-0.8 instead of 1.0?
Even highly productive teams lose meaningful time to meetings, on-call/support duties, code review for others, onboarding, and context-switching between tasks — a focus factor below 1.0 acknowledges this rather than planning against an unrealistic 100% utilization assumption.
How do I calibrate focus factor for my team?
Compare actual completed story points against nominal capacity (members × hours ÷ hours-per-point) over several past sprints — the ratio of actual-to-nominal is your team's empirical focus factor, which is more reliable than guessing.
Should capacity planning account for partial-time contributors?
Yes — for team members who split time across multiple teams or have reduced availability (part-time, onboarding, planned leave), use their actual available hours for the sprint rather than a full nominal allocation.
Does higher focus factor always mean a healthier team?
Not necessarily — an unusually high focus factor (e.g. above 0.85) might indicate insufficient time for code review, learning, or support work, which can lead to burnout or quality issues even though it looks efficient on paper.
You might also need
- Sprint Burndown CalculatorCommonly used together
- Release Velocity CalculatorCommonly used together
- Error Budget CalculatorCommonly used together
- Engineering Productivity CalculatorAlso in DevOps Metrics & DORA
- Platform Reliability Score CalculatorAlso in DevOps Metrics & DORA
- DevOps Maturity Score CalculatorAlso in DevOps Metrics & DORA