Capacity Planning Template for Product Planning

Use whatever your team already estimates in. If your squads run sprints and track [velocity](/glossary/velocity) in story points, use story points. If your team does not estimate formally, use engineering days as a simpler starting point. The unit matters less than consistency. All squads should use the same unit so you can aggregate across the organization.

Budget a new hire at 0% capacity for their first 2 weeks (onboarding, setup, meetings). Then 30% for weeks 3-6 (paired work, small tasks). Then 50-70% for the rest of the quarter. They will not reach full velocity until next quarter. If a critical project depends on a new hire, that is a risk worth flagging.

Three options: cut scope (remove or defer initiatives), extend timelines (push some work to next quarter), or add capacity (hire, contract, or borrow from another team). This template makes the gap visible so leadership can make an informed trade-off instead of silently overcommitting.

Capacity planning operates at the quarterly level. The [Sprint Planning template](/templates/sprint-planning-template) operates at the sprint level. This template tells you "Squad A has 152 points for the quarter." Sprint planning then allocates those points sprint by sprint: "Sprint 1 gets 28 points from these 5 stories." Think of quarterly capacity planning as the budget and sprint planning as the spending.

Yes. Allocate 5-15% of raw capacity explicitly for tech debt and maintenance. If you do not protect this allocation, tech debt gets zero attention every quarter and compounds until it causes production incidents or slows feature delivery. Some teams dedicate one sprint per quarter entirely to tech debt. Others spread it across every sprint at a fixed percentage. Either works as long as the allocation is explicit and tracked. ---