Capacity planning that survives reality

Most teams plan against naive capacity — team size × sprint days. A six-engineer team running a two-week sprint shows 60 person-days of capacity. They commit to 60 days of work. They deliver 35.

The gap isn't laziness. It's that "person-days" is a fiction. Real engineers spend a third of their time on meetings, another fifth on interruptions, a tenth on PTO and on-call duty, and the rest on the work the team is actually tracking. Naive capacity over-commits by 40% because it counts every working day as a working day.

This article is the math, the anti-patterns, and the fix.

The numbers

We measured this across ~400 sprints in Stride telemetry (Q1 2026). The breakdown:

The number that matters: 52% active dev. Multiply that by your team size × sprint days to get realistic capacity.

For our 6-engineer 10-day sprint: 6 × 10 × 0.52 = 31 person-days. That's the upper bound on what you should plan, not 60.

Adjusting for your team

The 52% number is a median. Yours will be different — sometimes substantially. Real adjustments:

Increase your active-dev % if:

• Your team has fewer than 4 engineers (less code review overhead)
• You ship infrequently (fewer demos + releases)
• You run async (fewer meetings)
• You don't have a serious on-call rotation

Decrease your active-dev % if:

• You're in growth mode hiring (interview load is real, often 5-10% of senior time)
• Your on-call rotation is loud (every page is 30-60 min of focus tax)
• You have many cross-team dependencies (lots of "wait for the platform team" interrupts)
• You're a regulated industry (compliance reviews eat hours per sprint)

Calibrate quarterly. The 52% baseline is the starting point; the team-specific number is the planning input.

How to actually compute capacity

Three inputs you need before sprint planning:

1. Person-day availability per engineer

For each engineer, count working days in the sprint, then subtract:

• Known PTO (calendar entries marked Out of Office)
• Known training / conference days
• Known interview load (count hours; convert to days)

Output: per-engineer person-days for this sprint.

2. Team active-dev percentage

The 52% baseline (or your calibrated number). Multiply per-engineer days by this percentage to get effective person-days.

3. Velocity in points per effective person-day

From your last 6 sprints: total points completed ÷ total effective person-days available those sprints. This is your team's point-per-day rate. For most teams it's 1.5-3 points/day.

Putting it together

Effective capacity (points) = sum(per-engineer effective days) × points-per-day

For our 6-engineer team, 10-day sprint, 52% active-dev, 2 days of PTO this sprint, 2 points/day:

• Person-days: (6 × 10) - 2 = 58
• Effective days: 58 × 0.52 = 30.2
• Capacity: 30.2 × 2 = 60 points

You can pull about 60 points. Pulling 90 is over-commitment. Pulling 40 is under-commitment (which is its own anti-pattern — under-loaded teams produce thrash).

Anti-patterns we see

The Hero Sprint. "We have so much to ship — let's just commit to 80 and grind." The team commits, misses, retros, commits, misses, retros. Heroics aren't a planning strategy.

The Sandbagging Sprint. Team is burnt out from last sprint's over-commitment, so they pull half capacity. This is fine for one sprint as recovery. As a pattern, it tells the planner the team has no slack-recovery rhythm — fix the pattern, not the under-commitment.

The Mystery Capacity. "We always plan for 50, just because." When asked where 50 came from, nobody knows. Usually it's the highest number a previous team hit once.

The Ignored PTO. Three engineers on PTO and the team still plans for full capacity. Happens more than you'd think — usually because PTO isn't visible at planning time.

The Buffer-Free Sprint. No reserve for surprises. First production incident derails the entire sprint. Build a 15-20% buffer; expect to use it.

How Stride does this

In the Plan module: capacity is computed automatically from each engineer's PTO calendar, meeting load (pulled from Google Calendar / Outlook), and the team's historical velocity. The planner sees a per-engineer breakdown — actual available focus hours per day, not theoretical maximums — and the proposed sprint draft fits within that capacity by construction.

The user can still over-commit by hand. The friction is intentional: the system shows you when you're over, but doesn't block. Some sprints (a critical release, a hackathon-style push) genuinely need to over-commit. The point is to make it a conscious choice, not the default.

Read next

• Story sizing without flame wars — once you have capacity, you need consistent point estimates to plan against it.
• Sprint goals worth committing to — capacity tells you how much you can do; sprint goals tell you what's worth doing.
• Burndown charts and what they actually tell you — the metric that shows whether your capacity estimate was right.
• The story-points glossary entry and velocity glossary entry cover the inputs.