Most sprint commitments are wrong before they begin, not because the team misjudged the work, but because nobody calculated how much time the team actually had. Capacity planning is the practice of working that out in advance: how many usable hours does this team have this sprint or quarter, once you subtract leave, on-call, meetings, interruptions, and everything else that does not make it onto the ticket board? Done well, it converts an optimistic estimate into a realistic one and gives you something defensible to show stakeholders when they ask why the roadmap looks the way it does.
Most sprint plans fail not because the work was misjudged, but because nobody calculated how much time the team actually had. Capacity planning fixes that before the sprint starts, not halfway through it.
Capacity versus velocity
Before doing any calculation, it helps to be clear on what capacity actually means, because it is frequently confused with velocity. Velocity is a historical measure of how much work a team completed in past sprints. Capacity is a forward-looking measure of how much time the team has available in a specific upcoming period. Both are useful. Neither is the other.
The confusion matters because velocity-based planning assumes that every sprint will look like the previous ones. But sprints are not identical. One engineer is on holiday. Another is on-call and likely to be interrupted. You have a company all-hands taking up half a day. Planning from velocity without adjusting for capacity means committing to output that the available hours simply cannot support.
Velocity
Capacity
The most accurate approach uses both: start with your historical velocity as a reference, then adjust your commitment up or down based on how this sprint's capacity compares to a typical one. If you usually deliver 40 points in a two-week sprint but one engineer is away for the whole period, a commitment of 30-32 points is more honest than 40.
How to calculate usable capacity
The calculation itself is straightforward. For each engineer, start with the total working days in the sprint, then subtract everything that takes them away from focused delivery work. What remains is their usable capacity for the sprint. Summing this across the whole team gives you your total sprint capacity.
Capacity calculation per engineer
Run this for each team member, then sum the results for total team capacity.
The buffer for unplanned work is where most teams undercount. Every sprint contains work that does not appear on the board at the start: a colleague asking for help, an unexpected bug in production, a last-minute stakeholder request that cannot wait. If you do not build a buffer in, this work cannibalises planned delivery and the sprint ends with half the committed items incomplete.
How large the buffer should be depends on your team's history. If you track it over three or four sprints, you will quickly see how much unplanned work routinely appears. For most software teams, 15% is a reasonable starting point. For teams in operational or platform roles where interrupts are constant, 25-30% is more realistic.
The hidden drains on capacity
The obvious deductions - leave and holidays - are easy to account for. The harder ones are the drains that do not appear on anyone's calendar but reliably consume a significant slice of every engineer's week. If you ignore these, your capacity numbers will be consistently optimistic and your sprint commitments will consistently overrun.
- Code reviewFor most teams, reviewing pull requests takes between thirty minutes and two hours per engineer per day depending on team size and workflow. This work is invisible to many capacity models but is critical to delivery. If reviewing is not accounted for, either reviews pile up and slow delivery, or engineers skip them - neither outcome is good.
- Context switchingSwitching between tasks carries a real cost. A developer who moves between three different streams in a day is substantially less productive than one who stays in a single context. This loss does not show up as booked time but it reliably shows up as slower delivery. Teams with high interrupt rates need a larger unplanned buffer to compensate.
- Documentation and communicationWriting up decisions, updating Confluence, responding to Slack threads, preparing for the sprint review. These activities are not glamorous and do not map to tickets, but they are part of delivery and they take time. A rough rule is to expect five to ten percent of engineering time to be absorbed this way in a well-run team.
- Interviews and recruitingIf you are actively hiring, technical interviews consume several hours per week per participating engineer. This is often left out of sprint capacity entirely because it is managed through a separate process. Include it, especially when hiring is intense. Three technical interviews in a sprint week is half a day gone.
- Onboarding supportWhen a new engineer joins the team, their buddy or assigned mentor typically spends two to four hours per week supporting them for the first month or two. Factor this into the capacity of the engineer providing support, not just the new joiner.
Capacity planning at the quarter level
Sprint-level capacity planning tells you what a team can commit to in the next two weeks. Quarter-level capacity planning tells you whether a roadmap is achievable before you promise it to anyone. Both are necessary, but the quarter view is where most teams have the biggest gap. Roadmaps get signed off based on optimistic estimates that nobody has sanity-checked against available person-days.
A quarterly capacity model follows the same logic as a sprint one, just at a larger scale. Count the total working days across the quarter, subtract all known leave, public holidays, and recurring overhead, then compare the result against the rough estimates attached to the roadmap initiatives. If the initiatives add up to 200 engineer-days and the team has 140 days of usable capacity, something needs to move.
Quarterly capacity planning checklist
The point of this exercise is not to produce a precise forecast. It is to make the constraints visible early enough to do something about them. A capacity model that shows you are 30% over-committed in Q3 is not a failure. It is the information you need to have an honest conversation with your stakeholders about what is actually possible before you start missing deadlines.
Communicating capacity to stakeholders
One of the most valuable things capacity planning gives you is a factual basis for the conversations you need to have with stakeholders. "We cannot fit that into this quarter" is much stronger when accompanied by a model that shows why, rather than being a judgment call that can be argued against. Stakeholders who understand the constraints before the roadmap is locked are far less frustrated than ones who discover mid-quarter that something has slipped.
- Show the modelA simple spreadsheet or shared doc that shows available person-days alongside estimated initiative size is usually enough. You do not need sophisticated tooling. The goal is transparency, not precision. Seeing the maths makes constraints concrete in a way that verbal explanations rarely do.
- Translate to business termsStakeholders do not think in engineer-days. Convert your capacity model into something they can connect to: "We have capacity for two of the three features on the roadmap this quarter. Here are the trade-offs." Give them the decision, not just the data.
- Update when things changeCapacity changes throughout a quarter - an engineer goes off sick, a new hire joins, a planned initiative turns out larger than expected. A capacity model you never update is less useful than one that is refreshed as the situation evolves. A brief mention in your weekly update to stakeholders when capacity changes significantly keeps expectations current.
- Make leave visible earlySummer and winter periods with high holiday uptake can significantly reduce a team's output. Raising this early, ideally two to three months before the affected period, gives product and business stakeholders time to adjust their expectations rather than being surprised mid-quarter.
Common mistakes in capacity planning
Even experienced engineering managers fall into the same capacity planning traps. Recognising them makes it easier to avoid the optimism that tends to undermine sprint and quarter-level commitments.
- Planning for 100%No engineer is available for productive delivery work for 100% of their working hours. Planning as if they are means your model is wrong before the sprint starts. A usable capacity figure of 60-75% of total hours is typical for a healthy team. If your number is higher than that, revisit what you are accounting for.
- Not distinguishing types of workPlanned features, bug fixes, technical debt, on-call support, and team overhead all compete for the same pool of time. Treating them as the same category makes it impossible to see where time is actually going. Track them separately and you will quickly see which categories are consuming more than expected.
- Ignoring downstream dependenciesOne engineer waiting for a code review, an environment to be provisioned, or a stakeholder decision is not working at capacity even if they are technically available. Capacity planning that ignores these blockers overestimates how much will actually get done.
- Assuming equal capacity per personA junior engineer and a senior engineer are not interchangeable in a capacity model. Domain expertise, context, and skill level all affect output. A rough adjustment, treating a junior engineer as 60-70% of a senior's capacity for complex work, produces more accurate plans than treating all heads as equivalent.
- Never revisiting the modelA capacity model built once and never checked against reality quickly drifts out of date. Compare your planned capacity against what actually happened at the end of each sprint. If you consistently have 20% more unplanned work than you budgeted for, your buffer assumption is wrong. Update it.
Making capacity planning a habit
Capacity planning is most useful when it is a regular part of how your team works, not a one-off exercise before a big planning event. The easiest way to embed it is to attach it to ceremonies that already happen: run a brief capacity check as part of sprint planning, and do a fuller quarterly review alongside your planning sessions. Once the team is used to seeing the model, it takes five minutes to update rather than half a day to create from scratch.
The most important output is not a precise number. It is the discipline of asking the question before committing. How much time does this team actually have? What are we assuming about interrupts and overhead? Do the commitments we are about to make fit inside the time that is realistically available? Teams that ask these questions consistently before every sprint overcommit less, finish what they start, and are far less likely to need the awkward stakeholder conversation about why something has slipped again.
Capacity planning rhythm
Frequently asked questions
Keep your team's commitments visible
Track targets, actions, and progress in one place so capacity constraints never come as a surprise to you or your stakeholders.