Team Capacity Calculator

Calculate available engineering team capacity for a sprint accounting for time off.

About Team Capacity Calculator

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

Worked example

With the default values below, Team Capacity Calculator returns Effective Sprint Capacity of 336.0. Change any input above and every figure here is recalculated in your browser.

Inputs used

Team Membersaccepts 1–1,000 members: 6 members
Hours per Sprint (per member)accepts 0–1,000 hours: 80 hours
Focus Factoraccepts 0.1–1 ×: 0.7 ×
Avg Hours per Story Pointaccepts 0.1–1,000 hours/point: 4 hours/point

Results

Effective Sprint Capacity: 336.0 hours
Estimated Capacity: 84.0 story points
Nominal Hours (before focus factor): 480 hours
Hours Lost to Overhead: 144.0 hours

Step by step

1Nominal hours: members × hours/sprint= 480 hours
2Effective capacity: nominal × focus factor= 336.0 hours
3Estimated capacity in points= 84.0 points

Assumptions and limits

The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

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.