Your Sprint Capacity Is a Lie. Here’s the Real Number.

It’s Thursday afternoon. The sprint ends tomorrow.

Your board has 14 tickets still in progress. Three are blocked. Two engineers are on the same incident. The Slack thread with your VP is titled “quick question on the roadmap” and you have not opened it yet.

You did the math two weeks ago. Five engineers. Ten working days. Eight hours a day. Four hundred hours of capacity. The backlog you pulled in was sized for 380. Should have been a calm sprint.

It was never going to be.

The number you put into the plan was wrong before standup on day one. Not by a little. By half.

The 50% rule that nobody wants to say out loud

Here is the formula most planning tools quietly assume: team size × sprint days × 8 hours = capacity.

Here is the formula real teams ship against: that same number, multiplied by a focus factor somewhere between 0.5 and 0.7.

This is not a hack. It is the standard. Rock’s 2026 sprint planning guide puts it plainly: the capacity formula most teams converge on is team-member-days available × focus factor, where focus factor is typically 0.5 to 0.7. The 0.5 default goes back to Henrik Kniberg’s Scrum and XP from the Trenches, and the reasoning is brutal: half the team’s nominal hours go to meetings, context-switching, and unplanned work.

Half.

If your team is five engineers and your “capacity” is 400 hours, your real capacity is closer to 200. Maybe 280 on a clean sprint with no incidents.

You have been planning a sprint that was already 30% over before the planning meeting ended.

Why the gap is bigger than you think

The 50% number always shocks operators. Then they list what their week actually looks like and the shock fades.

Take one engineer. Two weeks. Eighty nominal hours.

·       Sprint planning, refinement, retro, demo: 6 hours

·       Daily standup × 10: 2.5 hours (with the inevitable five minutes of side-chat)

·       Code review across the team: 6 to 10 hours

·       One-on-ones, all-hands, ops calls: 3 to 5 hours

·       Slack and email triage: 5 hours minimum

·       Pairing or context-switching between two tickets: 3 to 6 hours

·       The production incident nobody planned for: 4 to 12 hours, twice a quarter

That is 30 to 45 hours gone before they write a line of code. And nobody on the team was slacking. They were doing the work that keeps the team functional.

This is the gap Tempo’s engineering capacity guide names directly: most teams run the calculation assuming eight full hours of focused work per day, but standups and ad-hoc requests eat into that window before the sprint even starts. The number going into the formula is wrong, and the team ends up overcommitting.

You are not bad at planning. You are using the wrong inputs.

The three signals you’re planning on lies

Before you change anything, check whether you actually have the problem. Three signs:

1. Your “estimation confidence” is high but your “completion confidence” is low. Engineers say they’re 80%+ sure on their ticket sizes. The sprint still ends with 30% of points unfinished. The estimates were fine. The capacity was fiction.

2. You quietly skip code review or QA to “save” a sprint. Then you spend the next sprint fixing the bugs that slipped through. Microsoft’s research and SmartBear’s 2,500-review study both found code review catches 20% to 90% of defects before QA, at roughly a tenth of the cost of catching them in production. Skipping it does not buy you time. It buys you incidents.

3. Velocity numbers swing 40%+ sprint over sprint. If your team completes 60 points one sprint, 95 the next, 55 the next, that’s not the team being inconsistent. That’s the capacity input being inconsistent and velocity absorbing the noise.

What to put on the board on Monday

Here is the rework, not as a framework, just as a recipe you can run this week.

Step 1: Calculate per person, not per team.

One engineer’s three-day conference does not “average out” across five engineers. It’s three full days off that engineer’s capacity. Total it individually, then sum.

Step 2: Subtract real overhead before applying the focus factor.

Take each person’s nominal hours. Subtract:

·       All scheduled meetings (ceremonies, one-on-ones, all-hands)

·       Known PTO, holidays, conferences, on-call rotations

·       Recruiting load (interviews are 1.5 hours each with prep and debrief)

What’s left is “available hours.” This is not your capacity yet.

Step 3: Multiply available hours by 0.6 for most teams.

Use 0.5 if your team has heavy on-call, frequent incidents, or a noisy Slack culture. Use 0.7 if you have a small team with light overhead and protected focus blocks. Track your actual focus factor for three sprints. Then use real data instead of the guess.

Step 4: Plan to that number. Hold the line.

This is the hard part. Your CEO will push for “one more thing.” Your sales lead will land a customer that needs a feature “by end of sprint.” Your VP will hint that the roadmap looks light.

It is not light. It is honest. The roadmap that looked heavy was the one losing 30% of its stories every sprint.

Jeff Sutherland, co-creator of Scrum, put it this way: heroic effort should be viewed as a failure of planning. Every “we just need to push through this sprint” is a quiet admission that the input number was wrong.

When the 50% rule is wrong

The rule has edges. Three cases where it bends:

Solo founders or two-person teams. Less ceremony overhead, more uninterrupted focus. You may genuinely run at 0.75 or 0.8. Track it for three weeks before you trust it.

Pure delivery sprints with no roadmap work. A team doing a fixed scope, no discovery, no design input, can hit 0.65 or 0.7 short-term. They burn out at that rate over a quarter.

Chaotic, interrupt-heavy ops teams. SRE-style or platform teams with on-call rotations and incident response often land at 0.4 or below. They should not pretend otherwise. Their planning input is real capacity, not idealized capacity.

The point is not to memorize a number. The point is to stop pretending one engineer = 80 productive hours per sprint, when every honest retro for the last six months has been telling you they have 40.

The artifact: a one-page capacity sheet for Monday morning

Copy this into a sheet, fill it in before your next planning meeting, and walk into the room with real numbers:

A team that thought it had 400 hours had 191. That’s not the team failing. That’s planning catching up with reality.

Build this once. Update it weekly. Watch the “we missed the sprint goal again” retros stop within a quarter.

If your team is shipping the same broken sprint on repeat and you need an extra senior squad to absorb the overflow without making your own team’s capacity worse, we’re built for that. We embed alongside in-house teams, work in your sprint cadence, and never put juniors on client code. See how we structure that work, or send us a 20-minute scoping call request and we’ll come back with a real estimate inside 48 hours.

P.S. The teams that escape the broken-sprint loop usually have one thing in common: they stopped using velocity as the planning input. Velocity is a long-run forecast. Capacity is what you commit to this sprint. If you’re using velocity where you should be using capacity, your retros will keep looking the same no matter who you hire.

P.P.S. If your current pain is “we keep shipping work that breaks in production because we cut review to fit the sprint,” that’s not a sprint problem. That’s a product audit problem. Different fix, same root cause: capacity planned on lies.