Home
Free tool

Sprint capacity calculator

Naive sprint capacity (team-size × sprint-days) overestimates by 40-50%. This calculator does the math from PTO, meetings, on-call, and your team's velocity history.

How it works

Edit any input on the left. The result panel on the right re-computes instantly. The breakdown shows where your team loses time to PTO, meetings, and on-call duty — the three biggest gaps between naive and realistic capacity.

No signup. No tracking. Pure client-side; nothing leaves your browser.

Your team

engineers

Engineers contributing this sprint. PMs / designers usually excluded.

days

Working days in the sprint. 5 for weekly, 10 for fortnightly.

days

Average across the team. Includes vacation, sick days, training, holidays.

hrs/wk

Standups + planning + retros + 1:1s + cross-team. 8 is healthy; 15+ is a smell.

engineers

On-call typically halves the on-call person’s sprint capacity.

points

Averaged across the last 3-5 sprints. Leave at 0 if the team has no baseline yet.

Recommended commit
23
story points

Scaled from your team's historical velocity by the utilization rate this sprint. Treat this as the upper bound on your sprint commit — leave room for surprise.

Naive capacity50 eng-days
– PTO2.5
– Meetings13.3
– On-call5
Effective capacity29.2 eng-days
Utilization58% (you lose 42%)

Why naive capacity is wrong by 40-50%

The naive formula — team-size × sprint-days — assumes every engineer works 100% of every workday on sprint stories. In practice, the gap between naive and realistic comes from three places:

  • PTOVacation, sick days, training, public holidays. Always averages out higher than the team thinks — over a quarter, it's typically 5-8% of available days.
  • MeetingsStandups (5h/wk), planning (2h/sprint), retro (1h/sprint), 1:1s, cross-team. 8 hours/week is healthy; 15+ is a smell. At 8 hours/week with a 2-week sprint, meetings consume 16 hours per engineer.
  • On-callEach on-call person loses ~50% of their sprint capacity to context switching, interrupt handling, and recovery time after pages. Teams that don't account for this systematically over-commit.

The full framework — including how to handle ramp-up time for new engineers, how to adjust for high-variance sprints, and when to NOT use a velocity model — read the sprint-planning hub article.

Want this built in?

Stride's Plan module pulls PTO from your HRIS, meetings from your calendar, and velocity from your sprint history. Capacity computes itself — no form to fill.

See AI sprint planning