What is Capacity Planning?
Capacity planning is the practice of estimating how much work your team can realistically take on during a sprint, quarter, or release cycle. It accounts for team size, individual availability, meetings overhead, technical debt work, and unplanned interruptions.
Without capacity planning, teams default to wishful thinking. They commit to more than they can deliver, miss deadlines, and burn out. Good capacity planning creates a feedback loop between ambition and reality.
Why Capacity Planning Matters
Product managers who skip capacity planning consistently overpromise to stakeholders. When a team commits to 40 story points but can only deliver 28, trust erodes fast. Stakeholders stop believing the roadmap, and the PM loses credibility.
Capacity planning also forces prioritization. When you know you have 30 points of capacity, you have to choose between Feature A and Feature B rather than pretending both will fit.
How to Do Capacity Planning
Start with your team's historical velocity. If they averaged 25 story points over the last 4 sprints, that is your baseline. Adjust for known absences: holidays, PTO, training days.
Factor in maintenance work. Most teams spend 15-25% of capacity on bugs, on-call, and technical debt. Build that into your plan rather than pretending it will not happen.
Leave a buffer. A team running at 100% capacity has zero room for surprises. Target 80% utilization and you will actually hit your commitments.
Capacity Planning in Practice
Spotify famously uses squad-level capacity planning where each squad owns its allocation between new features, quality improvements, and tech debt. The split is visible to leadership but decided by the squad.
At Atlassian, teams use a 70/20/10 model: 70% planned feature work, 20% technical health, 10% exploration. This gives PMs a predictable budget for feature delivery while maintaining system health.
Common Pitfalls
- Ignoring meeting overhead. Engineers in 3 hours of meetings daily do not have 8 productive hours. Account for this.
- Planning to 100%. Unexpected work always appears. Plan to 80% and treat the buffer as a feature.
- Not tracking actuals. Capacity planning only improves when you compare planned vs. actual delivery each sprint.
- Treating all engineers as interchangeable. A backend engineer cannot do iOS work. Plan capacity by skill area.
Related Concepts
Capacity planning connects directly to sprint planning and story points. It is informed by your team's velocity and helps prevent scope creep. For quarterly planning, pair it with OKRs to align capacity with strategic priorities.