Capacity Is Not a Commitment: Planning Software Work Under Uncertainty

A team has three engineers and ten working days until a planned release. The calendar seems to offer 30 engineer-days of capacity. A new warranty-registration feature is expected to require fewer than half that amount. On the surface, the work appears to fit.

But the feature needs a server-side registration record before the frontend can complete the customer journey. The engineer who can change that service is also handling existing work and production support. Only two of that person’s days are unallocated, while the proposed service change is expected to need four.

The problem is not that the team cannot add up hours. It is that a total of available effort does not show whether the necessary people, work, and verification can line up before release.

This example is hypothetical. It is not a description of a team I managed, a missed deadline, or measured delivery performance. I use it to examine a planning problem that appears in many long-running software products: when can available capacity reasonably support a delivery forecast, and when does calling that forecast a commitment conceal information people need?

Capacity answers a different question from delivery

Capacity is a statement about resources expected to be available over a period. It can help a team avoid planning more work than its people could possibly perform. But completing a feature also depends on the kind of work, which steps must happen first, the time needed for review and verification, and the interruptions that occur while delivery is in progress.

Three engineers are not thirty interchangeable days of engineering skill. One might understand the customer-account service, another the frontend, and another the test environment. They can help one another, but transferring specialized work may require knowledge, permissions, or coordination that is not available within the same window.

The distinction matters when a capacity figure travels outside the engineering conversation. “There are 18 days available” may be heard as “we can deliver 18 days of new functionality.” That conclusion has added assumptions that the number itself does not support.

A capacity calculation must show what it excludes

For the illustrative ten-day period, assume the team consists of a frontend engineer, an API engineer, and a cross-functional engineer who can handle integration and verification. The starting roster offers 30 engineer-days. The team already knows about three days of leave, four days reserved for support work, and five days allocated to existing in-flight work.

Assume these allocations do not overlap. The remaining unallocated budget is 18 engineer-day equivalents. This is planning arithmetic, not a guarantee that 18 days of uninterrupted productive work will occur.

The remaining days are distributed unevenly. The frontend engineer has nine; the API engineer has two after support and prior commitments; and the cross-functional engineer has seven. The proposed warranty registration needs an illustrative five days of frontend work, four days of API work, and three days of integration and verification. It totals 12 estimated effort-days—less than 18—but the API work does not fit that engineer’s current allocation.

The table exposes the difference between a plausible aggregate calculation and an actual delivery constraint.

A different specialist might be able to take the API work, but that has to be demonstrated rather than assumed. The feature’s estimate also needs to include completing the workflow and testing an accepted registration. Counting only coding and adding testing later would make the apparent spare capacity less meaningful.

The bottleneck is often a sequence, not a person’s workload

Even if the API engineer unexpectedly gains two more days, the release may still be at risk. The frontend can implement a form against an agreed contract, but the complete registration journey must be integrated, tested, and accepted after the server behavior is ready. Two activities can fit separately into the calendar while their required sequence does not.

This is the difference between effort and elapsed time. A change may require a modest amount of concentrated work yet wait several days for a shared reviewer, test environment, external service, or release window. Adding everyone’s free days together obscures those waits.

It is also why splitting work into many parallel tickets does not necessarily make delivery faster. If each one converges on the same integration or review stage, more started work can build a larger queue instead of producing more finished outcomes.

The useful planning question is not only how many tasks can be started. It is which complete customer capability can move through the constrained path and reach the team’s agreed standard of Done.

Historical throughput helps—but only when it describes comparable work

A forecast should not rely solely on the latest estimate from the person implementing the feature. Teams can inspect what they have actually finished, how long work typically remains in progress, and whether blocked items are aging beyond expectations.

The May 2025 Kanban Guide defines throughput as a count of finished work items per unit of time, cycle time as elapsed time from starting to finishing an item, work item age as the elapsed time of unfinished work, and work in progress as items started but not finished. These measures reveal different aspects of delivery flow.

Throughput is not an amount of engineer-days. Ten tiny fixes and ten integrated features are both ten completed items unless the comparison also accounts for what an item represents. A historical rate from a stable workflow can be a useful forecasting input; a rate drawn from fundamentally different work or changing team capacity needs more caution.

The same guide describes service level expectations as forecasts with an elapsed-time period and a probability, informed by historical cycle time. That is more honest than presenting one calendar date as certain when delivery times vary. It also requires enough relevant observations: with little comparable history, the team should say its forecast is tentative rather than invent a precise percentage.

In our example, past frontend throughput may help size familiar interface work. It cannot independently predict when a specialized registration service will be ready if that dependency is unlike the team’s recent completed items.

In Scrum, the Sprint Goal is the commitment—not every selected item

The 2020 Scrum Guide is precise about Sprint Planning. Developers select work with the Product Owner and build a forecast informed by past performance, upcoming capacity, and the Definition of Done. The Sprint Backlog contains the Sprint Goal, selected items, and a plan for delivering them.

The Sprint Goal is the commitment for that artifact. Treating every selected backlog item as an individually guaranteed delivery promise is a stronger claim than the framework makes. Scope can be clarified and renegotiated as more is learned without sacrificing quality or endangering the Sprint Goal.

Outside Scrum, teams may have contractual deadlines or business commitments that are entirely real. The point is not to rename those obligations as forecasts. It is to make the evidence and trade-offs behind them visible. A date does not become achievable simply because it has been promised.

An honest plan therefore distinguishes the intended outcome, the work currently forecast to produce it, and the constraints that could require an authorized change to scope, capacity, or timing.

A delivery plan needs decisions for when assumptions fail

For the hypothetical warranty feature, the API availability is an explicit assumption and a visible bottleneck. The team has several legitimate responses. It might free the required specialist capacity by moving another commitment, verify that another engineer can safely complete the service work, negotiate a genuinely smaller end-to-end capability, or shift the date.

None of these is automatically free. Moving work affects another stakeholder; cross-training can take time; a narrower feature must still deliver an honest customer outcome; and changing a deadline may affect a campaign or dependent team. The purpose of planning is to expose these consequences while alternatives still exist.

The second table shows how I would keep the next decision attached to the evidence that prompts it.

A disabled frontend behind a feature flag may be a valid deployment step, but it is not delivery of warranty registration. If the service cannot save a registration or the team cannot verify the complete outcome, the customer-facing capability is not finished simply because the UI has been merged.

The earlier estimating problem—deciding which missing facts could change the size of a feature—is explored in What Engineers Need to Know Before They Can Estimate a Feature.

Do not turn uncertainty into permanent overtime

When a forecast becomes uncomfortable, teams sometimes protect the date by silently assuming extra hours, fewer reviews, or verification after release. This may make the schedule look unchanged while moving the cost into fatigue and product risk.

A better response is to identify the changing constraint. If the capacity loss is temporary, discuss when the work can resume. If the integration contract is missing, give the investigation an owner and an explicit decision point. If a new urgent incident consumes the same specialist, update the forecast and explain what the interruption displaced.

This is not a request for unlimited buffers or an argument that engineers should never commit to ambitious goals. Deliberate commitments are useful. They become more credible when capacity planning acknowledges variability and the release plan includes meaningful ways to respond to it.

Communicate a forecast as a decision, not a reassurance

For this fictional release, a useful update to stakeholders would be something like:

We have 18 unallocated engineer-days across the team, but only two are currently available from the engineer needed for the registration service. The feature is estimated at 12 effort-days overall, including four for that service. We can proceed with the frontend and confirm the interface contract now, but the customer-facing registration is not yet a credible commitment for this release. To keep the date, we need either an agreed change to the API engineer’s priorities or a verified smaller end-to-end scope. Otherwise, we should move the feature rather than remove its verification.

This gives a decision-maker useful choices. It also says what is already known, what must change, and why additional developers elsewhere in the team cannot automatically remove the bottleneck.

A forecast should be revisited when the relevant evidence changes: service access is confirmed, a blocked item becomes ready, an incident consumes capacity, or the team demonstrates a faster complete path. Re-estimation without new information can become repetitive ceremony; ignoring new information turns the original number into fiction.

The strongest plan protects the outcome, not the appearance of full utilization

A capacity plan can be accurate as arithmetic and poor as a delivery plan. The missing information is often not another estimate. It is the sequence of work, the scarce capability, the actual standard of completion, and the decision that follows if an assumption fails.

A useful engineering forecast combines available capacity with relevant delivery history, explicit dependencies, and a credible route to a complete result. It is transparent about what remains uncertain and about the commitments that would need to change if the evidence changes.

That is the difference between being busy enough to fill a calendar and being ready to promise an outcome.