How to Calculate and Manage Scrum Team Capacity

Capacity in scrum represents the total amount of time a team has available to work on sprint backlog items. It accounts for the human reality of the workplace, including meetings, holidays, and administrative tasks.

Visualizing team availability is the first step in effective scrum capacity planning.

To calculate capacity in scrum, you must determine the total available hours for every team member. This requires looking at the sprint duration and subtracting non-development time.

01
Identify the total number of working days in the sprint.
02
List every team member and their daily working hours.
03
Subtract planned time off, holidays, and company events.
04
Deduct 'overhead' time for scrum ceremonies (daily standups, retro).
05
Apply a focus factor to account for context switching.

A standard formula helps engineering leaders maintain consistency. Start with the gross hours and work down to the net available hours for the sprint.

system.log

Info.

// The Capacity Formula

No developer is 100% productive for 8 hours a day. Most high-performing teams use a focus factor between 0.6 and 0.8 to ensure realistic commitments.

70%

Average Focus Factor

10-15%

Ceremony Overhead

25%

Predictability Gain

Velocity is a historical average of story points completed. Capacity is a forward-looking measure of available hours. You need both for velocity and capacity planning in scrum to be effective.

Trade-off

3 pros · 3 cons

Pros

Capacity: Accounts for real-time availability
Capacity: Highlights individual bottlenecks
Capacity: Prevents over-commitment

Cons

Velocity: Ignores upcoming vacations
Velocity: Doesn't account for new hires
Velocity: Can be skewed by 'point inflation'

0/6

When scaling software engineering teams, capacity often dips temporarily due to onboarding and mentorship requirements. Leaders must factor in this 'onboarding tax'.

If your team consistently misses sprint goals despite careful planning, you may need to identify bottlenecks in the workflow that are siphoning off productive hours.

Unplanned 'emergency' bugs
Excessive cross-departmental meetings
Context switching between multiple projects
Vague requirements leading to rework
Technical debt slowing down new features

One of the most overlooked aspects of scrum team capacity planning is the time required for managing technical debt. High debt levels act as a tax on every hour worked.

timeline.stream

01 / 05

phase 01 / 05
Calendar Audit
phase 02 / 05
Individual Input
phase 03 / 05
Aggregation
phase 04 / 05
Buffer Application
phase 05 / 05
Final Commitment

Factor	Calculation	Total Hours
Gross Hours	5 devs x 10 days x 8 hrs	400
Ceremonies	15 hrs per dev	-75
PTO/Holidays	1 dev off for 2 days	-16
Net Capacity	309 hrs x 0.7 focus	216.3

PlaybookDo

Use a consistent focus factor across sprints
Track 'actual vs planned' capacity to improve accuracy
Include QA and Design in the capacity model
Protect the team from mid-sprint scope creep

PlaybookDon't

Plan for 100% utilization (burnout risk)
Ignore historical velocity trends
Forget to account for interview time during hiring
Use capacity as a performance stick

While spreadsheets are a common starting point, modern engineering teams often use integrated tools to automate the calculation of scrum team capacity.

Burn-down charts reflect capacity reality.

Over-estimating capacity leads to a 'hero culture' where developers work overtime to meet impossible goals. Consistent capacity management is a key tool for long-term retention.

Predictability isn't about working harder; it's about knowing exactly how much space you have to work effectively.
Alex Rivera · VP of Engineering

Focus factor is the percentage of time a developer spends on actual sprint tasks versus administrative overhead. A 0.7 factor is standard for most healthy teams.

Once you have the basics down, the next step is refining your process. This involves looking at how your team handles unplanned work and refining your focus factor over time.

tasks.queue

Review last sprint's actual hours worked
Adjust focus factor based on historical data
Audit recurring meetings for relevance
Standardize story point estimation

Calculating capacity is a tactical necessity, but it's only one part of a high-velocity engineering culture. At Studio 402, we help teams move beyond simple metrics to build durable systems.

If your team is struggling with unpredictable shipping cycles or technical debt that eats your capacity, our engineering leadership advisory can help you stabilize and scale.

Helping growth-stage teams increase sprint predictability by 40%.

Based on 2026 engineering audit data.