Capacity Planning
What Is Capacity Planning?
Capacity planning is the process of comparing expected work with the time, skills, and availability a team can realistically provide over a defined period. It helps teams make credible commitments, expose bottlenecks, and decide which work to sequence, reduce, defer, or support with additional appropriate resources.
For product teams, capacity includes more than engineering headcount. Design, research, quality assurance, platform support, and specialist reviews can each constrain what can be completed. The relevant constraint depends on the work being considered.
Available Time Is Not the Same as Headcount
A person employed for a full week may spend part of it on support, recurring responsibilities, leave, coordination, or another team's commitments. Planning as if all paid hours are available for new product work creates a false baseline.
Start with realistic availability for the planning period and account for obligations that already consume it. A team charter can clarify recurring responsibilities, but current availability still needs to be checked with the people doing the work.
Keep the unit consistent. Hours or person-days can describe available time. Story points describe a team's relative estimation of work and should not be converted into universal productivity units or compared directly across unrelated teams.
A Simple Capacity Planning Example
Imagine a small product team planning a two-week period with ten working days per person. Three engineers provide a nominal thirty person-days. Planned leave removes three days, while support rotation and existing obligations take another six. That leaves twenty-one person-days for the work being considered, before any additional allowance for uncertainty.
These figures are illustrative. They do not recommend a fixed utilization rate or buffer for every team. The team's historical experience and current risk should inform how much work it is comfortable committing to.
Now suppose the release requires a security review from a specialist who has only one available day. Extra general engineering time does not remove that bottleneck. The plan must change the scope, review sequence, timing, or access to the required expertise.
Capacity, Demand, and Dependencies
Demand is the work being requested. Capacity is what can realistically be supplied. Estimation helps describe the effort and uncertainty of demand; it does not create more available capacity.
A roadmap dependency can also prevent progress even when the team has available time. A mobile feature that needs an unfinished platform API cannot be made ready simply by assigning more mobile developers to it.
Make those constraints visible alongside the product roadmap. If planned demand exceeds available capacity, name the trade-off rather than preserving every commitment through an optimistic date change.
Capacity Planning vs. Resource Planning
Capacity planning asks how much relevant work can be supported within the period. Resource planning concerns how specific people or other resources are allocated. The terms overlap in practice, so define the question before comparing plans.
In a cross-functional team, allocation by role can reveal a shortage hidden by total team availability. A team may have enough combined hours but too little research or specialist review time for the proposed mix of work.
When Should the Plan Be Reviewed?
Review capacity when commitments, staffing, leave, operational load, or the nature of the work changes. Compare the plan with actual constraints to improve the next estimate, rather than using every difference as evidence that someone worked too slowly.
The purpose is a usable planning boundary. A detailed spreadsheet that assumes constant availability is less helpful than a simple, regularly corrected view of what the team can support. Capacity planning does not guarantee a delivery date; it makes the assumptions behind that date easier to examine.