Capacity Based Work Selection

Capacity Based Work Selection is the method of choosing how much and which work to bring into an iteration by anchoring the decision to the team's realistic, quantified capacity to deliver, rather than to optimism, external pressure, or the raw length of the prioritized backlog. It treats capacity as a hard constraint that shapes selection from the outset, rather than a factor consulted only after an aspirational scope has already been chosen.

Foundations of the Approach

Capacity as a Finite, Measurable Resource

Every iteration, a team has a bounded amount of productive time available, determined by team size, iteration length, and the proportion of time consumed by non-development activities such as meetings, support duties, and administrative work. Capacity based selection starts by quantifying this bound explicitly rather than assuming it.

Historical Evidence Over Forecasted Optimism

Rather than estimating capacity from theoretical availability alone, this approach relies heavily on the team's actual historical throughput, since past performance under real conditions is a more reliable predictor of what can be delivered than a theoretical calculation of available hours.

Selection as a Constrained Optimization

Given a fixed capacity, the team selects the highest-value combination of ready backlog items that fits within that constraint, treating the selection process as similar to filling a fixed container with the most valuable items that fit, rather than open-ended scope negotiation.

Determining Capacity

Nominal Capacity Calculation

The starting point is the theoretical maximum: team size multiplied by the number of working days in the iteration, expressed in hours or an equivalent unit.

Adjusting for Known Reductions

Planned absences, holidays, recurring meeting overhead, and dedicated support or maintenance time are subtracted from the nominal figure to produce a more realistic estimate.

Calibrating Against Historical Velocity

The adjusted figure is further calibrated against the team's actual historical velocity, since teams consistently overestimate how much of their nominal time translates directly into completed feature work.

Applying Capacity to Selection

Establishing a Selection Ceiling

The calculated capacity, often expressed in story points or estimated hours, sets a firm ceiling for how much estimated work can be pulled into the iteration.

Selecting in Priority Order Until Capacity Is Reached

Items are added to the iteration in priority order, with running totals tracked against the ceiling, until the next item would exceed available capacity.

Reserving Buffer for Uncertainty

Many teams deliberately select slightly below full calculated capacity, preserving a buffer to absorb estimation error, minor scope discoveries, or unplanned interruptions without immediately breaking the iteration commitment.

Reassessing Mid-Selection

If early items in priority order turn out to consume more capacity than expected once discussed in detail, the team recalculates remaining capacity before continuing to select further items.

Benefits of Capacity Based Selection

More Reliable Commitments

Because scope is bounded by realistic capacity rather than aspiration, the resulting commitments are more likely to be met, strengthening trust between the team and its stakeholders over successive iterations.

Sustainable Team Pace

Anchoring selection to genuine capacity, rather than repeatedly stretching to accommodate stakeholder pressure, helps the team avoid the chronic overtime and burnout that erode long-term productivity.

Early Visibility Into Scope Constraints

When capacity clearly cannot accommodate all desired high-priority work, this becomes visible during planning itself, giving stakeholders the opportunity to make informed trade-off decisions early rather than discovering shortfalls late in the iteration.

Common Failure Modes

Using Theoretical Rather Than Historical Capacity

Relying solely on nominal hours without calibrating against actual historical throughput consistently produces overcommitted iterations, since real-world productive time is always lower than raw availability suggests.

Ignoring Capacity Fluctuations

Failing to adjust capacity for known upcoming absences or organizational events results in a plan that looks reasonable on paper but is unachievable given the team's true availability during that specific iteration.

Treating Capacity as a Target Rather Than a Ceiling

Deliberately selecting work to exactly match or slightly exceed calculated capacity, rather than leaving appropriate buffer, removes the safety margin needed to absorb the estimation variance that is inherent in software work.

Allowing Non-Development Work to Go Unaccounted

Omitting recurring but non-feature-related work, such as production support or cross-team collaboration, from the capacity calculation leads to systematic overcommitment even when the formal calculation appears rigorous.