Capacity planning is the discipline of understanding how much work your team can handle and allocating that capacity strategically across competing priorities. Get it right, and your team delivers predictably while maintaining sustainability. Get it wrong, and you face either burnout from overcommitment or wasted potential from underutilisation.
Understanding Your Team's True Capacity
Your team's capacity is not the number of engineers multiplied by forty hours per week. Real capacity accounts for meetings, on-call duties, code reviews, mentoring, vacation, sick time, and the cognitive overhead of context switching. A realistic estimate of productive engineering time is typically fifty to sixty percent of total available hours.
Historical data is the best predictor of future capacity. Track how much work your team actually completes per sprint - not how much they planned, but how much they delivered. Over several sprints, a pattern emerges that gives you a reliable baseline for planning. This throughput-based approach is far more accurate than theoretical capacity calculations.
- Productive engineering time is typically fifty to sixty percent of total hours
- Historical throughput is the best predictor of future capacity
- Account for meetings, on-call, reviews, mentoring, and context switching
- Theoretical capacity always overstates what teams can actually deliver
Forecasting Demand
Demand forecasting requires understanding both planned and unplanned work. Planned work comes from your roadmap: features, projects, and initiatives with defined scope. Unplanned work includes bugs, production incidents, support requests, and ad-hoc stakeholder requests. Most teams underestimate unplanned work significantly.
Track the ratio of planned to unplanned work over time. If your team consistently spends thirty percent of its capacity on unplanned work, factor that into your forecasts. A plan that assumes one hundred percent of capacity is available for planned work will fail every time. Realism in forecasting builds credibility with stakeholders and protects your team from overcommitment.
Look ahead at least one quarter. What major initiatives are coming? What new responsibilities are being added? What attrition might you face? Longer-range forecasting is inherently less precise, but even rough estimates help you identify capacity gaps before they become crises.
Allocating Capacity Strategically
Divide your team's capacity across four categories: feature delivery (new functionality for users), reliability and maintenance (keeping existing systems healthy), technical debt reduction (improving the codebase), and team investment (learning, documentation, tooling). The right allocation depends on your team's context, but a common starting point is sixty percent feature delivery, fifteen percent reliability, fifteen percent debt, and ten percent investment.
Protect non-feature allocations from being raided during delivery pressure. If you consistently sacrifice reliability, debt, and investment for feature delivery, you create a doom loop where system fragility and team burnout eventually make feature delivery slower and more painful. Sustainable velocity requires balanced allocation.
- Allocate capacity across features, reliability, debt, and team investment
- Sixty-fifteen-fifteen-ten is a reasonable starting allocation
- Protect non-feature allocations from delivery pressure
- Imbalanced allocation creates long-term velocity problems
Building in Buffer and Contingency
Every capacity plan needs buffer for the unexpected. Reserve fifteen to twenty percent of capacity as buffer for unplanned work, emergencies, and estimation errors. This buffer is not waste - it is the margin that allows your team to respond to reality without derailing planned work.
When buffer is consistently consumed, it signals that your estimates or demand forecasts need adjustment. When buffer is consistently unused, you may be under-planning. Track buffer consumption over time and adjust your planning accordingly.
Common Capacity Planning Mistakes
The most common mistake is planning to full capacity. This leaves no margin for the inevitable surprises that arise during every sprint. The resulting constant state of overcommitment burns out the team and erodes trust with stakeholders when commitments are consistently missed.
Another frequent error is treating all capacity as interchangeable. An available backend engineer cannot fill a gap in frontend capacity. Skills, domain knowledge, and context mean that capacity is not fungible. Plan at the skill level, not just the headcount level.
Key Takeaways
- Base capacity on historical throughput, not theoretical calculations
- Factor unplanned work into every forecast - typically twenty to thirty percent
- Allocate capacity across features, reliability, debt, and team investment
- Reserve fifteen to twenty percent buffer for the unexpected
- Plan at the skill level, not just the headcount level
Frequently Asked Questions
- How do I handle requests that exceed my team's capacity?
- Be transparent about the trade-off. Present your current commitments and capacity, then ask the requester what they would deprioritise to make room for the new request. If nothing can be deprioritised, the request needs to wait or additional resources need to be secured. Never quietly add work beyond your team's capacity - this leads to overcommitment and missed delivery.
- How do I account for new hires in capacity planning?
- New hires are net negative on capacity for their first one to three months. They consume senior engineers' time through onboarding, mentoring, and code reviews while producing limited output. Plan for a new hire to reach fifty percent productivity by month two and full productivity by month three to six, depending on the role's complexity and the engineer's experience level.
- Should I plan capacity quarterly or per sprint?
- Both, at different levels of detail. Quarterly planning provides the strategic view: major initiatives, headcount changes, and capacity allocation across categories. Sprint-level planning provides the tactical view: specific stories, task assignments, and week-to-week adjustments. Quarterly plans set the boundaries; sprint plans fill in the details.
Download Capacity Planning Tools
Access capacity planning spreadsheets, demand forecasting templates, and allocation frameworks designed for engineering managers planning team capacity strategically.
Learn More