How to calculate team capacity for a sprint in Linear

2 min read · Capacycle

Most sprint planning starts with a backlog and ends with a gut-feel commitment. That's how teams end up overcommitted every cycle. Capacity planning flips it: you figure out how much time the team actually has first, then decide what fits.

Here's a practical way to calculate it for a Linear cycle.

The honest formula

capacity = engineers × cycle_days × focus_hours_per_day
         − PTO
         − on-call hours
         − interview hours
         − meeting overhead
         − expected interruptions

The mistake is starting from 8 hours × 5 days × N engineers. Nobody ships 40 focused hours a week. Realistic focus time for most engineering teams lands between 3 and 5 hours per working day, and that's before on-call or interview load.

Step-by-step for a 2-week Linear cycle

1. Start with headcount-days. 6 engineers × 10 working days = 60 engineer-days.

2. Subtract time off. Check calendars. If two people take 2 days each: −4 days. Down to 56.

3. Subtract on-call. Whoever's on primary usually loses 30–50% of their cycle. If one person is on-call the full two weeks, subtract ~5 days. Down to 51.

4. Subtract interviews and recurring meetings. Estimate per-person load. If everyone loses ~1 day to meetings and two people do 4 hours of interviews: ~7 days. Down to 44.

5. Apply a focus factor. The remaining days aren't 8-hour days. Multiply by 0.5–0.6 to get effective hours. 44 × 0.55 × 8 = ~194 focus hours.

That's the real number. For most teams, it's 40–50% of the naive headcount math.

Doing this in Linear

Linear doesn't expose a native capacity view, so you have to assemble it:

Estimates on every issue. Use points or hours consistently. Without this, there's nothing to compare capacity against.
A "Cycle planning" view filtered to the upcoming cycle, grouped by assignee, summed by estimate.
Labels for non-delivery work — oncall, interview, meeting, support. Create issues for these and assign them so they count against capacity, not against slack.
A team-level view that shows committed estimate vs. calculated capacity per person.

Most teams skip step 3 — the non-delivery issues — and then wonder why velocity "dropped." It didn't drop; the invisible work just stayed invisible.

Common mistakes

Treating velocity as capacity. Velocity is what you delivered last cycle, not what you can deliver next cycle. If someone leaves or on-call rotates, last cycle's number is wrong.
Ignoring the estimate-to-reality gap. If your team routinely delivers 70% of estimates, plan for 70%. Don't plan for 100% and call the shortfall "scope creep."
Forgetting the person doing planning. The lead planning the cycle loses meaningful time to planning itself. Count it.

The shortcut

If the math feels heavy: rule of thumb for most Linear teams is 40–55% of naive capacity. A 6-engineer, 2-week cycle with 480 naive hours is realistically 190–260 focus hours. Plan to that, not to 480.

Capacity planning isn't a science. But even a rough, honest number beats the ambitious fiction most teams commit to.