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:

Time category	Median %
Active development (the work tracked in stories)	52%
Meetings (standup, planning, demos, 1:1s, all-hands)	18%
Code review (others' PRs)	10%
Interruptions / async support / on-call	8%
PTO / holidays	7%
Other (training, hiring, admin)	5%

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.