Capacity planning is the practice of understanding your engineering team's available bandwidth and allocating it effectively across competing demands. For engineering managers, getting capacity planning right means delivering on commitments without burning out the team, while maintaining room for technical investment, learning, and unexpected work. This guide covers both tactical sprint capacity and strategic headcount planning.
Understanding Engineering Team Capacity
Engineering capacity is not simply the number of engineers multiplied by the hours in a workday. Real capacity accounts for meetings, on-call duties, code reviews, mentoring, learning time, and the inevitable overhead of context switching between tasks. A common rule of thumb is that engineers spend fifty to sixty percent of their time on direct feature development - the rest goes to necessary overhead.
Capacity varies by individual and by period. A senior engineer mentoring two juniors has less individual coding capacity but generates more team output. An engineer on-call for a week has reduced feature capacity. Holiday periods, company events, and end-of-quarter pushes all affect available capacity. Planning that assumes constant, uniform capacity inevitably produces missed commitments.
Understanding your team's actual capacity requires measurement, not estimation. Track how much of each sprint's planned work is actually completed over time. This empirical throughput - not theoretical capacity - should be the basis for future planning. Most teams discover that their actual throughput is significantly lower than their theoretical capacity, and this gap represents the overhead of organisational life.
- Real engineering capacity is fifty to sixty percent of total available time
- Capacity varies by person, by week, and by organisational context
- Measure actual throughput over time rather than estimating theoretical capacity
- Account for on-call, mentoring, code review, and learning time in capacity plans
- Over-commitment is the most common capacity planning failure - always leave buffer
Sprint-Level Capacity Planning
Sprint capacity planning starts with the team's historical velocity - how many story points or items the team typically completes per sprint. Use the average of the last three to five sprints as your baseline, not the team's best sprint. Planning to the best sprint sets the team up for failure; planning to the average sets them up for consistent delivery.
Adjust the baseline for known capacity changes in the upcoming sprint. If a team member is on holiday for three of ten days, reduce the capacity by roughly that proportion. If the team has a production on-call rotation that typically consumes one person's capacity, deduct that from the plan. Build these adjustments into a simple sprint capacity calculator that the team uses at the start of each sprint planning session.
Reserve ten to twenty percent of sprint capacity for unplanned work. This includes production incidents, urgent bug fixes, and requests that cannot wait for the next sprint. Teams that plan to one hundred percent capacity inevitably miss their sprint commitments because they have no room for the unexpected. The reserved capacity is not wasted - it provides the flexibility that makes sprint commitments reliable.
Strategic Capacity Allocation Across Work Types
Beyond sprint-level planning, engineering managers need a strategic view of how team capacity is allocated across work types. A common allocation framework divides capacity into four categories: feature work (new functionality requested by product), technical investment (debt reduction, platform improvements, tooling), operational work (on-call, incident response, routine maintenance), and learning and growth (training, experimentation, hackathons).
A healthy allocation for most product engineering teams is approximately sixty to seventy percent feature work, fifteen to twenty percent technical investment, ten to fifteen percent operational work, and five to ten percent learning. Teams that allocate one hundred percent to feature work accumulate technical debt until their velocity collapses. Teams that allocate too much to technical investment frustrate product stakeholders with slow feature delivery.
Make your capacity allocation visible to stakeholders. When the product manager understands that eighty percent of the team's time goes to features and twenty percent goes to technical health, they can make informed trade-off decisions. Without this transparency, stakeholders assume one hundred percent feature capacity and are perpetually disappointed by the pace of delivery.
Headcount Forecasting and Planning
Headcount planning connects engineering capacity to business strategy. Start with the planned roadmap and work backward: what capabilities does the organisation need to deliver its strategic objectives? How many engineers are needed to provide those capabilities at a sustainable pace? What skills gaps exist in the current team? These questions inform your headcount request.
When building a headcount case, quantify the trade-offs. Instead of simply requesting more engineers, present the options: 'With current headcount, we can deliver either Project A or Project B this quarter, but not both. An additional two engineers would allow us to deliver both.' This framing helps leadership make informed decisions about investment versus speed.
Account for ramp-up time when planning headcount. A new hire does not reach full productivity for three to six months, depending on the complexity of the codebase and domain. During the ramp-up period, they also consume the capacity of senior engineers who provide mentoring and code review. This means that hiring to solve a near-term capacity problem requires planning six to nine months in advance.
Preventing Burnout Through Sustainable Capacity Planning
Burnout is the inevitable result of consistently operating above capacity. The signs are subtle at first - declining code quality, increased irritability, resistance to new initiatives, and growing cynicism about the team's ability to succeed. By the time burnout is obvious, significant damage has been done to individual wellbeing and team culture.
Sustainable capacity planning builds slack into the system. This is not idleness - it is the space that allows teams to absorb variability, respond to unexpected demands, and invest in improvement. Teams that operate at one hundred percent utilisation are brittle; teams that operate at eighty percent are resilient. The twenty percent slack is what makes the eighty percent productive.
Monitor leading indicators of unsustainable workload: increasing overtime, growing sprint carryover, declining time for code review and testing, and team members skipping learning activities. When these indicators trend negatively, reduce the team's commitments before burnout sets in - do not wait for people to break down. As the engineering manager, protecting the team's sustainability is one of your most important responsibilities.
Key Takeaways
- Plan to your team's average throughput, not their theoretical capacity or best sprint
- Reserve ten to twenty percent of sprint capacity for unplanned work to maintain reliable delivery
- Allocate capacity strategically across features, technical investment, operations, and learning
- Make capacity allocation visible to stakeholders to set realistic expectations
- Build slack into the system - eighty percent utilisation is more productive than one hundred percent
Frequently Asked Questions
- How do you handle stakeholders who want one hundred percent of the team's capacity for features?
- Use data to illustrate the consequences. Show how teams that allocate one hundred percent to features see declining velocity over time as technical debt accumulates. Present the technical investment allocation as insurance that protects feature delivery velocity in future quarters. Many stakeholders accept a fifteen to twenty percent investment when they understand that it sustains the team's ability to deliver features quickly over the long term.
- How do you account for meetings and overhead in capacity planning?
- Measure it. Track how much time your team spends in meetings, on-call, doing code reviews, and handling administrative tasks over a two-week period. Most teams find that thirty to forty percent of their time goes to these activities. Factor this into your capacity calculations by using the team's actual throughput rather than theoretical capacity. If meeting overhead is excessive, reduce it - but account for whatever remains in your plans.
- Should you track individual engineer utilisation?
- Generally, no. Tracking individual utilisation incentivises busyness over effectiveness and creates an environment where people feel pressured to appear productive rather than actually being productive. Track team-level capacity and throughput instead. If you suspect an individual capacity issue, address it through one-on-ones and observation rather than utilisation metrics. The exception is tracking allocation across projects when engineers split time between multiple teams.
Try the Capacity Planning Tools
Use our sprint capacity calculator, strategic allocation tracker, and headcount planning model to improve capacity planning for your engineering team.
Learn More