What is the difference between capacity and velocity?

Capacity measures how much time your team has available to work, while velocity measures how much work your team actually completes (usually in story points). Capacity is an input - it tells you what's possible. Velocity is an output - it tells you what's realistic based on past performance. Teams often conflate these, leading to over-commitment.

How much work can my team complete in a sprint?

The most accurate answer comes from your own historical velocity, not a formula. Track completed story points over 3-5 sprints and use the average as your baseline. New teams without history should start conservative (60% of calculated capacity) and adjust after each sprint. Remember that velocity naturally varies - a range (e.g., 40-50 points) is more realistic than a single number.

Why is my team consistently missing sprint commitments?

The most common cause is underestimating overhead. Teams often plan for 100% coding capacity when reality is closer to 50-60%. Other culprits include: not accounting for unplanned work (typically 15-25% of capacity), ignoring context-switching costs between tasks, and optimistic estimation bias. Track where time actually goes for 2-3 sprints before adjusting your capacity calculations.

Should I include all engineers in capacity planning?

Include everyone who will contribute to sprint work, but weight appropriately. Senior engineers often spend more time on code reviews and mentoring (reduce by 20-30%). On-call rotations should reduce that person's capacity by 30-50% during their rotation. New team members ramping up might only contribute 50% of a full engineer's capacity. Part-time or shared resources should be counted at their actual availability.

All Free Tools

For Engineering Managers3 min

Team Capacity Planner

Calculate your team's actual coding capacity. Account for meetings, holidays, and other overhead to plan sprints realistically.

Most teams plan a sprint as if everyone codes the full day, every day. Then the standups, reviews, on-call pages, and a couple of sick days quietly eat a third of the week, and the sprint slips again. The hours that survive that pile of overhead are the only ones you can actually commit against.

This planner takes the raw size of your team - people, sprint length, working hours - and strips out meetings, paid time off, and the everyday operational load. What is left is effective coding capacity: the hours that turn into shipped work, plus a rough story-point range so you can size the backlog without guessing.

It is built for engineering managers and team leads who keep committing to more than the calendar can hold. The point is not to squeeze people harder. It is to commit to a number you can hit and stop treating overhead as if it were free.

Team Configuration

Number of EngineersHow many people on your team?

Sprint Length (days)Duration of your sprint or iteration

Working Hours per DayStandard work day length

Meeting Overhead (%)Standups, planning, retros, 1:1s, etc.

PTO/Holidays During SprintTotal days off across the entire team

days

Other Overhead (%)Code reviews, on-call, support tickets, context switching

Team Velocity RatingUsed for story point estimation

Enter the number of engineers above to calculate your team's capacity.

Capacity Planning Tips

Common Capacity Planning Mistakes

- Over-committing by ignoring meeting time (the "100% capacity" trap)
- Not accounting for context switching costs between tasks
- Forgetting about unplanned work (bugs, support escalations)
- Using the same capacity for all sprint types (planning sprints need more time)
- Not adjusting for holidays or team members ramping up

Tips for Protecting Maker Time

- Designate "no meeting" blocks or days for deep work
- Batch meetings together to minimize context switching
- Set realistic on-call rotations that don't fragment everyone's week
- Build in buffer time (10-15%) for unexpected work
- Track actual vs. planned capacity over multiple sprints to calibrate

Low Velocity

8-10 hours per story point. Use for new teams, unfamiliar codebases, or high-uncertainty work.

Medium Velocity

5-7 hours per story point. Use for established teams with familiar patterns and processes.

High Velocity

3-5 hours per story point. Use for experienced teams with well-defined, routine work.

How it’s calculated

The planner starts from theoretical capacity, then peels overhead off in layers until only coding time remains. Each input maps directly to one of those layers, so you can see where the hours go rather than trusting a single fudge factor.

Inputs

Number of engineers contributing to sprint work.
Sprint length in working days and standard hours per day.
Meeting overhead as a percent: standups, planning, retros, 1:1s.
Team-wide PTO and holidays falling inside the sprint, counted in days.
Other overhead as a percent: code review, on-call, support tickets, context switching.
A velocity rating (low, medium, high) used only for the story-point estimate.

Formula

Theoretical hours = engineers x sprint days x hours per day. PTO comes off first as team days x hours per day. Meeting and other overhead are then taken as percentages of the hours that remain after PTO, not of the full theoretical total - so leave and overhead do not double-count the same hours. Effective coding hours = hours after PTO minus meetings minus other overhead. Capacity percent is effective coding hours over theoretical hours.

Story-point range

The velocity rating sets an hours-per-point band: low is 8 to 10 hours a point, medium is 5 to 7, high is 3 to 5. Dividing effective coding hours by that band gives a low-to-high point range rather than a single false-precision number. Treat it as a sanity check on your backlog, not a target.

Why the result lands near 50 to 60 percent

Even strong teams spend only about half to two-thirds of their time on code. The rest goes to review, planning, and communication that the work genuinely needs. A green result here sits at 50 percent or higher, amber at 40 to 50, and red below 40. Pushing the number past 70 usually means you have hidden overhead somewhere, not found a faster team.

Worked example

Take a team of 5 engineers, a 10-day sprint at 8 hours a day, 20 percent meetings, 15 percent other overhead, and 3 team PTO days across the sprint.

Theoretical hours: 5 x 10 x 8 = 400 hours.
PTO: 3 days x 8 hours = 24 hours, leaving 376 hours.
Meetings: 20 percent of 376 = about 75 hours.
Other overhead: 15 percent of 376 = about 56 hours.
Effective coding hours: 376 - 75 - 56 = about 245 hours, or roughly 61 percent of theoretical.

The read: this team has about 245 real coding hours, not 400. At a medium velocity of 5 to 7 hours a point, that is roughly 35 to 49 points of work. If the backlog going into planning is 70 points, the problem is not effort - it is a commitment built on hours that were never going to exist.

Our Take

Sprint planning that ignores maintenance load and unplanned work is planning to fail. Elite teams account for 20-30% capacity loss to operational work.

The teams that consistently deliver aren't the fastest coders - they're the best estimators. They know exactly how much capacity meetings, code reviews, support escalations, and context switching consume. Most teams underestimate overhead by 30-40%, leading to chronic over-commitment and burnout.

"Teams that track actual vs. planned capacity improve estimation accuracy by 35% within 3 sprints."
— Software Engineering Management Research, 2023

Key terms

Theoretical Capacity: The raw maximum: engineers times sprint days times hours per day, before any overhead. It is the headline number planning tends to anchor on and the one this tool deliberately discounts.
Effective Coding Hours: The hours left for actual development after PTO, meetings, and other overhead are removed. This is the number you should commit work against.
Overhead: Time the team spends on work that is not direct coding - meetings, code review, on-call, support, and the cost of switching between tasks. Necessary, but not capacity you can fill with backlog.
Capacity vs Velocity: Capacity is an input: how much time the team has available. Velocity is an output: how much work it actually finishes, usually in story points. Capacity says what is possible; velocity says what is realistic from past results.
Maker Time: Uninterrupted blocks long enough for focused engineering work. Fragmenting it with scattered meetings and pages lowers real output even when total hours look unchanged.

Frequently Asked Questions

Sprint capacity is calculated by multiplying the number of engineers by available work days by hours per day, then subtracting overhead. A typical formula: (Engineers x Days x Hours) - Meetings - PTO - Other Overhead = Effective Capacity. Most teams end up with 50-65% of theoretical capacity available for coding. Use your actual historical data from 3-5 sprints to calibrate estimates rather than relying on industry averages.