What is the formula for sprint capacity?

Available capacity = (working days in the sprint × capacity per day) − public holidays − planned time off − overhead. Capacity per day is hours per day if you plan in hours, or points per day if you plan in story points. Do this per person, then sum for the team total.

Should I plan to 100% of capacity?

No. Planning to 100% leaves no room for the bug, the urgent meeting, or the estimate that runs long — so you miss your commitment. Most teams plan to 70–80% of calculated capacity. The remaining buffer is what absorbs the reality that no sprint goes exactly as planned.

How do I account for meetings and on-call in capacity?

Treat them as overhead — a fixed deduction per person per sprint, sometimes called the capacity "tax." Estimate the recurring load (standups, reviews, 1:1s, on-call shifts, support rotations) in your planning unit and subtract it before you assign work. It's the single most commonly forgotten input, and often the largest.

How do you calculate capacity in story points instead of hours?

Use a points-per-day figure derived from your team's history instead of hours per day. If a developer reliably completes about one point per day, then ten working days is roughly ten points of capacity, minus time off and overhead expressed in points. Hours tend to be more precise; points are faster once your velocity is stable.

What's the difference between capacity and velocity?

Velocity is how much work your team actually completed in past sprints, on average. Capacity is how much time or points are available in the upcoming sprint. Velocity is a backward-looking sanity check; capacity is the forward-looking budget. Good planning uses both — capacity to set the ceiling, velocity to reality-check it.

How to calculate team capacity for a sprint (and what everyone forgets)

Most capacity calculations are wrong in the same direction: too high. The team looks at “five engineers, two weeks” and pencils in ten working days each, fifty person-days total, and plans accordingly. Then the sprint ends at 60% done and everyone’s confused.

The number was never real. It ignored the holiday, the two people with PTO, the on-call rotation, and the genuinely staggering amount of time that gets eaten by meetings. Let’s fix that — here’s how to calculate capacity in a way that survives contact with an actual sprint.

The formula, plainly

Capacity for a single person is:

Available = (working days × capacity per day) − public holidays − time off − overhead

Where capacity per day is either hours per day (if you plan in hours) or points per day (if you plan in story points). You run this per person, then add everyone up for the team total. That last term — overhead — is the one people skip, and it’s the whole reason their plans don’t hold.

Let’s take each piece in turn, because the devil’s genuinely in the details here.

Working days

Start with the calendar days in the sprint, then strip out weekends. A two-week sprint is 14 calendar days but 10 working days. Easy enough — until a public holiday lands in the middle, and suddenly it’s 9. Don’t eyeball this; count it.

Capacity per day

How much productive work fits in a day? Not eight hours. Nobody does eight focused hours. A realistic figure is six hours of actual task work per day for a full-time person — the other two go to email, context-switching, and being a human. (This is the “focus factor” idea: teams typically assume only 60–80% of paid hours turn into sprint work.) If you plan in story points instead, use a points-per-day rate from your own history rather than a guess.

Public holidays

Org-wide days off — national holidays, company shutdown days. These hit everyone, so it’s tempting to handle them at the team level. Just don’t forget that not everyone shares the same calendar; a distributed team has people on different national holidays in the same sprint.

Time off

Individual PTO, sick days, that person leaving early Friday for a flight. This is per-person and it’s lumpy — one teammate might be out the entire sprint while everyone else is fully present. Partial days count too; half a day off is half a day of capacity gone.

Overhead — the “tax” everyone forgets

Here’s the big one. Every person loses time every sprint to work that isn’t sprint work:

Daily standup (15 min × 10 days = 2.5 hours right there)
Sprint ceremonies — planning, review, retro
1:1s and team meetings
Code review (real time, and a lot of it)
On-call and production support rotations
Interviews, mentoring, the random “got a sec?” that turns into 40 minutes

Some teams call this the capacity tax, and naming it helps, because once it has a name you stop pretending it’s free. For a lot of engineers this quietly adds up to 20–30% of the sprint. Skip it in your math and you’ve over-committed every single person, every single sprint.

A worked example

Let’s run the numbers for one developer in a two-week sprint, planning in hours.

Working days:           10
Hours per day:           6
─────────────────────────────
Total possible:         60 hrs

Minus public holiday:   −6 hrs   (one company day off)
Minus PTO:             −12 hrs   (two days out)
Minus overhead/tax:    −10 hrs   (standups, reviews, on-call)
─────────────────────────────
Available capacity:     32 hrs

So this person’s “60 hours” is actually 32 hours of assignable work — barely over half. If you’d planned them at 60, or even a “conservative” 48, you set them up to fail before the sprint started.

Now scale that across a team. Here’s six people, same two-week sprint:

Person	Total possible	Holidays	Time off	Overhead	Available
Ana	60 hrs	6	0	8	46 hrs
Ben	60 hrs	6	12	8	34 hrs
Cara	60 hrs	6	0	14 (on-call)	40 hrs
Dev	60 hrs	6	18	8	28 hrs
Eli	60 hrs	6	0	8	46 hrs
Fran	60 hrs	6	6	8	40 hrs
Team	360 hrs	—	—	—	234 hrs

Theoretical capacity: 360 hours. Real capacity: 234 hours. That’s a 35% gap between the number teams feel like they have and the number they actually have. Plan against 360 and you’re cooked. Plan against 234 — and then take 80% of that as your commitment, around 187 hours — and you’ve got a sprint that finishes.

Then take 80%

One more move, and it’s non-negotiable. Don’t plan to your full available capacity either. Things go wrong. A story balloons, a critical bug jumps the queue, someone gets pulled into an incident. Reserve roughly 20% as buffer and commit to the remaining 80%. Teams that do this hit their sprint goals consistently. Teams that don’t spend every retro explaining variance.

Hours or points?

You can run this whole exercise in story points instead of hours — swap “hours per day” for “points per day” based on your historical velocity, and express PTO and overhead in points too. Hours give you more precision and are easier for new teams; points are faster once your velocity has settled and they sidestep arguments about exact durations. Neither is wrong. We dug into the trade-off in story points vs hours for capacity planning. The one thing that is wrong is mixing units mid-sprint.

Why this is so painful in plain Jira

Notice that none of the numbers above live in Jira. Jira knows your story points and your burndown. It does not know Ben’s PTO, Cara’s on-call week, or your company holiday. So teams build the calculation in a spreadsheet, by hand, and then squint back and forth between the spreadsheet and the board while assigning work. It’s tedious, it goes stale the moment someone’s plans change, and it’s why capacity is the step that quietly gets skipped.

This is the gap Ekko closes. It reads the actual sprint dates from your Jira board, lets each person log their PTO and per-person overhead once, applies your org holidays, and then shows available-versus-assigned capacity right beside the plan — recalculating the instant you reassign or re-estimate anything. The exact mechanics are in the capacity calculation docs. The point is you stop maintaining the spreadsheet, because the math just sits next to the work.

The takeaway

Capacity isn’t “how many people times how many days.” It’s that number minus holidays, minus time off, minus the overhead tax — and then knocked down another 20% for reality. Do it honestly and your sprints get boringly predictable. Which, when you’ve lived through the alternative, is exactly what you want.