Ten working days. Five engineers. On paper that's 50 person-days of sprint capacity. In practice, most teams will plan against a number closer to 30 — and the gap between those two numbers is exactly where overcommitted sprints come from.
Most teams don't calculate capacity at all. They look at how many points closed last sprint, write a similar number on the whiteboard, and call it planning. That's not a capacity estimate — it's a lagging average that happens to work until it doesn't: someone takes PTO, a release week eats two days in meetings, or a senior engineer picks up an on-call rotation, and the plan is wrong before day one is over.
Velocity and capacity are not the same number
Velocity measures what the team shipped. Capacity measures what the team has available for the sprint ahead. They converge over long, stable stretches with a consistent team and no surprises — which is precisely the condition most small engineering teams don't have. A new hire ramping up, a founder pulled into sales calls, a production incident that eats Tuesday — velocity absorbs all of that after the fact, as a lower number next sprint. Capacity is supposed to account for it before you commit, and that only works if you actually calculate it instead of borrowing last sprint's total.
The subtractions nobody writes down
Getting from "team size" to "real sprint capacity" is arithmetic, not guesswork. Most teams skip straight from step 1 to step 5.
1. Start with raw person-days. Team size × working days in the sprint. This is the number everyone defaults to, and it's the least useful one on its own.
2. Subtract known time off. PTO, holidays, conferences, planned leave. If it's already on a calendar, it isn't sprint capacity.
3. Subtract fixed recurring load. On-call rotations, support tickets, code review for other teams, standing meetings. This is the subtraction teams skip most often, because none of it feels like "real work" until you add it up over two weeks.
4. Apply a focus factor to what's left. Even a fully available person doesn't spend 100% of the day on sprint work — Slack, unplanned interrupts, and context switching are real costs. Most teams land somewhere between 70-85% once they've measured it for a few sprints, not guessed it once.
5. Leave a deliberate buffer, not an accidental one. Planning to 100% of calculated capacity means any single surprise — a blocked dependency, a flaky deploy — turns into carryover. Planning to roughly 85-90% of calculated capacity means it doesn't.
> Capacity isn't a number you set once at planning and forget. It's the number that should still be true on day six of the sprint — which is exactly the point where most teams stop tracking it and start guessing again.
A worked example
Say a five-person team is planning a standard ten-day sprint. Nobody is on PTO, but one engineer has a two-day conference, and the team collectively spends roughly four hours a week each on support rotation and cross-team code review.
- Raw capacity: 5 engineers × 10 days = 50 person-days
- Minus the conference: −2 person-days → 48
- Minus support/review load (0.8 days/person/week × 5 people × 2 weeks): −8 person-days → 40
- Apply a 75% focus factor: 40 × 0.75 = 30 person-days
- Buffer to 85% of that for the actual plan: ~25.5 person-days
That's the number the sprint should be planned against — not the 50 person-days a headcount-based estimate would suggest, and not last sprint's velocity if last sprint had a different mix of leave and support load. The gap between 50 and roughly 25 is not a rounding error; it's the difference between a sprint the team finishes and one that carries two tickets into the next one.
Why this math usually lives in a spreadsheet, not the sprint tool
Most sprint boards show story points and a burndown line, but nothing that connects "how full is this sprint" to "how much capacity does the team actually have left." That forces the calculation above into a side spreadsheet that's accurate on the day it's built and stale by day three.
Spryn keeps capacity and scope visible on the same screen as you build the sprint, not as a separate report: as work is pulled in, you see capacity used against capacity available before you commit, not after the first standup reveals the sprint was never realistic. The AI sprint planner drafts a first pass from your backlog and current team capacity rather than a template, and the Timeline view carries a capacity-percentage row alongside scheduled work so overload is visible across weeks, not just within a single sprint. Mid-sprint, if scope grows past what capacity allows, that shows up as a signal on the board itself — the same subtraction from the worked example above, kept current instead of calculated once and abandoned.
None of that replaces the arithmetic — it just means the arithmetic doesn't go stale the moment the sprint starts.
If your team is still planning against last sprint's velocity because nothing shows real capacity while you're building the sprint, that's worth fixing before the next planning meeting, tool or no tool. If you want to see what capacity-aware planning looks like in practice, spryn.io/product walks through the planning and timeline views in more depth, and spryn.io/pricing has the self-hosted licence details — a one-time purchase with unlimited seats, so the cost doesn't change whether the team doing this math is five people or twenty five.