← All resources
Planning guide
16 min read

Sprint Capacity Planning: A Practical Team Guide

Teams don't miss sprint goals because estimation is broken. They miss them because planning ignores who's actually available and what reliably drains their time.

Try Ibis Flow free
See estimation features
The commitment isn't the problem. The missing context is.

Sprint planning feels comprehensive. The team reviews the backlog, the Host walks through priorities, estimates are discussed, stories are pulled in. Everyone nods. Two weeks later, half the work sits unfinished, scope gets pushed, and the retrospective circles around the same tired question: why did we overcommit again?

The problem is rarely the estimates themselves. It's the capacity calculation — or more often, the complete absence of one. Teams pull in 42 points because they completed 42 points last sprint, without asking whether this sprint has the same team, at the same availability, with the same overhead. They don't. It never does. The sprint is overloaded before the first standup.

This guide walks through three approaches to capacity planning grounded in engineering reality: velocity-based, available-hours, and hybrid. More importantly, it shows where each approach breaks down in the wild, and how to capture the context that makes the planning actually stick.

Why sprints fail before they even start

Sprint overcommitment follows predictable patterns. The first step to fixing it is recognizing which trap you're in.

The four capacity traps

The velocity mirage

A team completed 42 points last sprint. They pull in 42 points this sprint. But one developer is on leave, the sprint includes a bank holiday, and refinement overran by two sessions. Actual capacity: 30 points. The maths was never done.

The two-backlog shadow world

The team has accumulated a long tail of half-finished work and tech debt while simultaneously fielding new feature requests from stakeholders. Sprint planning pulls from both backlogs. Focus splits. Nothing finishes. The shadow backlog never gets ruthlessly prioritized down to 'Won't Have', so it silently consumes capacity every sprint.

The release management drain nobody counted

The previous sprint's work shipped yesterday. Today, the most senior engineers are shepherding the release, monitoring dashboards, fielding questions from support, and fixing the edge case that only appears in production. Not every team has push-button CI/CD. Risk management falls on experienced shoulders. The current sprint's capacity just lost 20% and planning didn't account for it.

The context-switch penalty

Not all working hours are development hours. Code review, Slack, support rotation, ad-hoc questions from other teams, and the perpetual pull of 'quick questions' consume 30–40% of developer time. A sprint built on raw hours always overshoots.

Sprint failure caused by overcommitment is not a discipline problem. It's an accounting problem. The team didn't fail to deliver — the plan ignored the actual constraints from the start.

What capacity planning actually delivers

A team that grounds its sprint commitment in realistic capacity — accounting for actual availability, meeting overhead, historical focus, and the hidden drains nobody wants to admit exist — will deliver more consistently. Not because they're working harder. Because the commitment was honest to begin with.

Consistent delivery builds organizational resilience. Stakeholders stop second-guessing estimates. Engineering Leads stop fire-fighting overcommitment. The team stops having the same retrospective every fortnight. Boring, predictable delivery beats heroic thrashing every time.

The number produced by a capacity calculation isn't the goal. The goal is capturing enough context — who's on leave, what release work is still in flight, where the hidden overhead lives — that the sprint commitment feels achievable before the work even starts.

Context is the load-bearing structure

The teams that plan capacity well don't just run the numbers. They capture the *why* behind every miss. Forgot to account for the bank holiday? Write it down. Release management ate Wednesday and Thursday? Note it. Over time, the boring mechanics of context capture make capacity planning nearly automatic.

Three approaches to sprint capacity planning

There is no single correct method. The right approach depends on your team's size, stability, and the data you have available. These are the three most widely used:

A

Option A: Velocity-based

Use the trailing average of completed story points from the last three sprints as your capacity signal. Simple, self-calibrating, and low overhead — but assumes team composition is stable.

B

Option B: Available-hours

Count each person's working hours, subtract ceremonies and known overhead, then apply a focus factor. Transparent and adjustable — but requires discipline to calibrate accurately.

C

Option C: Hybrid (velocity + availability overlay)

Use velocity as a baseline, then scale it proportionally for known capacity changes this sprint. Combines empiricism with explicit awareness of availability.

Option A: velocity-based planning

Velocity-based planning uses your team's historical story point output as the primary capacity signal. The most common implementation: take the average of the last three completed sprints and use that number as your planning target.

How it works
  1. Track how many story points the team actually completes (not just starts) each sprint
  2. Average the last three sprints: (Sprint N-1 + Sprint N-2 + Sprint N-3) / 3
  3. Use this average as your sprint capacity target for Sprint N
  4. Pull backlog items until you reach or approach that target
  5. Recalculate every sprint — the rolling average self-corrects over time
Where velocity-based planning works well
  • Established teams with stable membership over multiple sprints
  • Teams where sprint availability is broadly consistent (no seasonal leave peaks)
  • Backlog work of varying complexity where relative sizing is well-calibrated
  • Teams that want a low-overhead method with minimal ceremony
  • When stakeholders understand velocity and use it for release forecasting
Where it breaks down
  • The oscillating velocity pendulum — new teams plan high, miss badly, plan low the next sprint, overachieve, then swing wildly for months. They're chasing a number without understanding the capacity underneath it. The solution: switch to strict available-hours planning for the first 3–4 sprints, capture the *why* behind every miss (forgot the bank holiday, release work bled into the sprint), and transition back to velocity once the pendulum steadies.
  • Team composition changes shift capacity immediately — a new hire or departing member affects output right away, but the velocity average lags by 2–3 sprints before it reflects the new reality
  • Sprints with unusual capacity (holiday cluster, on-call incident, all-hands week) drag down the average even though this sprint is full strength — the anomaly distorts future planning
  • When velocity becomes a management target — teams inflate estimates or carry over stories to protect the number, rendering it useless as a planning signal
  • For teams in their first three sprints — there is no meaningful average yet; you're guessing
  • When teams compare velocity between squads — story points are local calibration, never universal currency

The pendulum warning sign

If your velocity swings by more than 20% between consecutive sprints and nobody can explain why, you're in the pendulum. Stop trusting the average. Audit actual availability, capture what drained capacity, and use available-hours planning until you understand the system you're measuring.

Option B: available-hours planning

Available-hours planning calculates capacity from the ground up: count real working time, subtract ceremonies and fixed overhead, and apply a focus factor that reflects how much of remaining time actually becomes productive development work.

The calculation
  1. List each team member and their working days this sprint (accounting for leave and public holidays)
  2. Multiply by working hours per day to get raw available hours per person
  3. Subtract recurring ceremony time: standup, planning, refinement, review, retro, 1:1s
  4. Subtract release management overhead if the previous sprint's work is shipping during this sprint — budget 10–20% of senior engineer time
  5. Apply a focus factor — typically 60–70% — to the remaining hours
  6. Sum across the team to get total 'focus hours' available this sprint
  7. Estimate stories in hours, or use your average points-per-focus-hour to convert

Understanding the focus factor and hidden overhead

Not all time outside meetings is deep development work. Code review, Slack, ad-hoc questions, context switching, incident response, and documentation consume a significant portion of every workday. The focus factor captures this reality. A typical software team runs 60–70% for experienced members, 50–60% for new starters still building context, and 40–50% for anyone on support rotation or shepherding a release through production.

Focus factor guidance by team profile

Established team, low support burden, no active release

65–70%

Experienced members, predictable work, minimal interruption

Typical cross-functional team

60–65%

Standard ceremony overhead, moderate code review and collaboration

Team with support rotation or active release management

50–60%

One or more members handling reactive work, production monitoring, or release shepherding

New team or onboarding member

50–55%

Higher context-building overhead; treat new starters as 25–50% capacity for their first sprint

A two-week sprint availability calendar grid with rows for each team member and columns for working days. Some cells are shaded to indicate leave and public holidays. The bottom row shows total person-days available, illustrating how real capacity differs from raw working hours.
Where available-hours planning works well
  • New teams without velocity history — provides structure before data accumulates
  • Sprints with known availability variations: leave, holidays, part-time participants
  • When stakeholders need an explicit, auditable capacity figure
  • Teams tracking both velocity and time, or shifting from hours to story points
  • When planning with contractors or part-time contributors at different allocations
Where it becomes difficult
  • Requires discipline to track and update the focus factor — if you set it once and never revisit it, you've embedded hidden assumptions that will drift from reality
  • Can encourage hour-level estimates if not managed carefully, undermining the benefits of relative sizing
  • The overhead calculation can feel bureaucratic on fast-moving teams who'd rather just start work
  • Focus factors don't self-correct the way velocity does — you have to actively review and adjust them based on what actually happened
  • If your team has wildly variable sprint-to-sprint overhead (release weeks vs feature weeks), a single focus factor won't capture the variance

Option C: hybrid (velocity + availability overlay)

The hybrid approach treats velocity as a reliable signal for a fully available team, then scales it proportionally when capacity changes. It answers the question: 'If our average sprint is built on 50 person-days of capacity, and this sprint we only have 40 person-days, what should our point target be?'

The calculation
  1. Calculate your baseline velocity: average story points completed in the last 3 sprints
  2. Calculate your average baseline capacity: team size × sprint days in the same period (e.g. 5 people × 10 days = 50 person-days)
  3. Calculate this sprint's capacity: count available people and days, adjusting for leave and public holidays
  4. Compute the capacity ratio: this sprint's capacity ÷ baseline capacity
  5. Set this sprint's target: baseline velocity × capacity ratio

Example

1
Baseline (last 3 sprints)

Average velocity: 40 points

Average capacity: 5 people × 10 days = 50 person-days

2
This sprint

1 developer on leave for 3 days, 1 public holiday → 46 person-days available

3
Calculate ratio

46 ÷ 50 = 0.92

4
Sprint target

40 points × 0.92 = 37 points

Where the hybrid approach excels
  • Teams with established velocity that have occasional leave, holidays, or part-time contributors
  • When you want to account for capacity changes without abandoning velocity as a planning signal
  • Transparent to stakeholders — the capacity ratio makes the adjustment visible and defensible
  • Scales naturally to multi-team programmes where capacity variance needs to be communicated
  • Preserves the self-calibrating properties of velocity while correcting for availability
Where it adds complexity
  • Requires at least three sprints of velocity data before it becomes meaningful — you can't baseline what doesn't exist yet
  • The person-day metric treats all team members equally — a senior engineer shepherding a release and a junior writing their first feature contribute very differently
  • More mental overhead than pure velocity during planning — you're doing two calculations instead of one
  • If your velocity baseline was itself affected by unaccounted capacity problems, the adjustment compounds the original error

A pragmatic default for established teams

For most teams with 3+ sprints of history, the hybrid approach balances simplicity and accuracy. It respects velocity's self-correcting nature while acknowledging that 'same team, same sprint length' is a fiction. If you're not sure where to start, start here.

Comparing the three approaches

No approach is universally superior. The right choice depends on your team's stage, stability, and planning culture.

Setup complexity

Velocity

Low

Hrs-based

Medium

Hybrid

Medium

Accuracy for stable teams

Velocity

High

Hrs-based

Medium

Hybrid

High

Accuracy when availability changes

Velocity

Low

Hrs-based

High

Hybrid

High

Transparency to stakeholders

Velocity

Medium

Hrs-based

High

Hybrid

High

Susceptibility to gaming

Velocity

Medium

Hrs-based

Low

Hybrid

Low

Maintenance overhead

Velocity

Low

Hrs-based

High

Hybrid

Medium

Suitable for new teams

Velocity

No

Hrs-based

Yes

Hybrid

No (needs baseline)

Self-correcting over time

Velocity

Yes

Hrs-based

No

Hybrid

Yes

Decision rules: which approach for your situation

Use these if/then patterns to choose and adapt your capacity planning approach based on what's actually happening.

  • If your team has three or more sprints of stable data and consistent membership → use velocity-based planning as your primary method, it's the lowest overhead
  • If your team is newly formed or in the first three sprints → use available-hours planning with a 50–60% focus factor until you have enough data to trust velocity
  • If your velocity swings wildly between sprints (the oscillating pendulum) → stop trusting the number, switch to available-hours for 2–3 sprints, and capture the *why* behind every capacity drain so you understand the system before resuming velocity-based planning
  • If your team has established velocity but someone's on leave, there's a bank holiday, or you're onboarding a new member → apply the hybrid adjustment to your velocity target rather than guessing
  • If you're actively releasing the previous sprint's work during this sprint and don't have fully automated CI/CD → explicitly deduct 10–20% of senior engineer capacity from your planning target, and in parallel, relentlessly improve the boring mechanics of your release process so this drain shrinks over time
  • If your team maintains two backlogs (new features + old technical debt) → ruthlessly prioritize the old backlog into 'Won't Have' for this quarter, execute a rapid burn-down of genuinely critical items, and forcefully transition back to a single source of truth; split focus kills sprint predictability
  • If stakeholders regularly question your capacity numbers → available-hours or hybrid approaches provide explicit, auditable figures that are harder to argue with
  • If a new team member is joining mid-sprint or has planned onboarding → treat their capacity as 25–50% of a full sprint, not full capacity; they're asking questions and building context, not shipping features
  • If you're forecasting more than two sprints ahead for release planning → use velocity-based trending but apply a 10–15% buffer to account for unplanned leave, capacity variance, and the reality that estimates three months out are never precise

What teams get wrong most often

Planning at 100% of last sprint's velocity by default

Velocity is a trailing indicator. It reflects a sprint that already finished, with a team that had a specific availability profile. Mechanically applying it to a sprint with different availability — someone on leave, a bank holiday, release work in flight — is the single most common source of overcommitment. Calculate capacity first, then pull in work.

Forcing everything into the two-week box when the SDLC doesn't fit

Complex architecture, design review, security approval, and realistic testing don't magically compress into a single sprint because agile says they should. Forcing it degrades quality. Acknowledge the real Definition of Done. Break work into logical value-creating phases (design/architecture first, dev/test second), or use dual-track workflows where discovery happens ahead of the dev sprint so the true cost is known when development begins.

Treating velocity as a target rather than a signal

When Engineering Leads or Project Managers ask 'why did velocity drop?', teams start protecting the number instead of reporting reality. Estimates inflate. Stories carry over artificially. Velocity becomes meaningless as a planning signal the moment it becomes a performance metric. Treat it as diagnostic data, not a goal.

Not accounting for onboarding or release management overhead

A new team member at full sprint count is not a full sprint of capacity. They're pairing, reading docs, asking questions, attending onboarding. Budget 25–50% for their first sprint. Similarly, releasing the previous sprint's work safely consumes significant senior engineer time in the current sprint. If you don't have push-button CI/CD, deduct 10–20% from planning targets during release weeks.

The number isn't the point. The context you capture is.

Sprint capacity planning is not a precision exercise. Every method in this guide involves approximation. Your focus factor won't be exactly right. Your velocity average won't predict the next sprint perfectly. That's fine. Chasing precision is a distraction.

What matters is that the team makes an honest commitment — one grounded in who's actually available, what overhead reliably drains time, what release work is still in flight, and what they've historically delivered under similar constraints. The method you use to arrive at that commitment is secondary to the discipline of asking the questions.

More importantly: capture the *why* behind every miss. Forgot the bank holiday? Write it down. Release management ate two days? Note it. The shadow backlog split focus again? Document it and ruthlessly prioritize it away. Over time, these boring mechanics of context capture make capacity planning nearly automatic. The oscillating pendulum steadies. The overcommitment pattern breaks. The retrospectives stop circling the same tired question.

Boring, predictable delivery beats heroic thrashing. Velocity-based, available-hours, or hybrid — the best approach is the one your team uses honestly, captures context from, and refines every sprint.

Story Points vs Hours How to Run Planning Poker

Plan sprints with context and confidence

Ibis Flow helps agile teams run inclusive Planning Poker sessions and capture the *why* behind capacity misses — so your sprint commitments are grounded in context, not guesswork.

Try Ibis Flow free
See estimation features