Capacity Plan

Origin & evolution

Capacity planning began in manufacturing and operations, where matching production capacity to demand was a measurable engineering problem. Agile teams adopted a lighter version through velocity and throughput, using a team's recent delivery rate to forecast🔮ForecastSales & RevenueA revenue forecastView reference → how much it could commit to next.

The decisive insight🔦InsightUser ResearchA synthesised finding from researchView reference → came from queueing theory. Kingman's formula, the VUT equation for mean wait time in a queue, shows that waiting time rises with utilisation in a way that turns sharply upward as utilisation approaches 100%. Donald Reinertsen carried this into product work in The Principles of Product Development Flow (2009): capacity utilisation increases queues exponentially, and a rough rule of thumb treats anything past roughly 80% as the point where queue times and work-in-progress begin to balloon. The practical lesson is that a team planned to full capacity has no buffer for the variability that is certain to arrive, so its delivery slows precisely when it can least afford to.

The field landed on planning to less than full load on purpose. Slack is the mechanism that keeps flow moving, and a capacity plan that ignores it is a forecast of delay dressed up as efficiency.

How it works in practice

A team of six has a nominal 30 person-days per two-week sprint. The capacity plan deflates that to reality: two engineers are part-time on an incident🚨IncidentDevOps & PlatformA production incidentView reference → rota (minus 4 days), one is on holiday (minus 5), recurring ceremonies and reviews take a day across the team (minus 6), and routine maintenance reliably consumes a fifth of what remains. Effective planning capacity comes to about 12 person-days, not 30.

The team commits to 10 days of feature⭐FeatureProduct SpecificationA product capability or featureView reference → work and holds the rest as buffer. A neighbouring team that committed its full 30 spends the sprint firefighting overruns, with new requests queueing behind blocked work. The first team ships what it planned and absorbs a mid-sprint escalation without derailing. The difference is the refusal to plan at 100%.

Capacity plan vs. its neighbours

• Resource allocation🥧Resource AllocationProgram ManagementAn allocation of team capacityView reference → decides how many people a team gets across the portfolio🧸PortfolioPortfolioA grouping of products by strategic axisView reference →. A capacity plan takes that headcount and works out how much the team can realistically deliver. Allocation sets the size; capacity planning tests what that size can carry.
• Velocity is an input, the historical delivery rate a capacity plan uses to forecast. The plan is the forward commitment built from velocity, adjusted for known absences and deliberate slack.
• Ceremony events such as planning, review, and retrospective🪞RetrospectiveTeam & OrganisationA team retrospectiveView reference → are part of the capacity a plan must subtract, not free time. A plan that books these as zero-cost overstates what the team can do.

In the graph

In the Unified Product Graph, capacity_plan🗓️Capacity PlanTeam & OrganisationA plan for allocating team capacity lives in the team-and-organisation region and binds to its owner through team_planned_via_capacity_planTeamplanned viaCapacity Planhierarchy, a hierarchical edge from team🫂TeamTeam & OrganisationA cross-functional teamView reference → to the plan that governs its load. Keeping the plan attached to a specific team is what makes the 100%-utilisation trap visible: a plan that commits a team beyond its deflated capacity is a queryable warning, not a buried assumption🤔AssumptionStrategyA belief taken as true that underpins a strategyView reference →. It sits next to resource_allocation🥧Resource AllocationProgram ManagementAn allocation of team capacityView reference → and ceremony🔔CeremonyTeam & OrganisationA recurring team ritual (standup, planning)View reference →, so the chain from portfolio staffing down to a single team's deliverable load, ceremonies and all, stays connected.