Capacity Planning vs. Pull-Based Scheduling

---

The Underlying Tension

Capacity planning is a push mechanism: the team forecasts how much work will fit in a sprint, commits to that amount, and pushes it through the system. Pull-based scheduling is the inverse: the team commits to no fixed batch, and pulls the next item only when capacity opens. This debate is a small instance of one of lean manufacturing's oldest arguments — push versus pull — applied to knowledge work.¹

The Case for Capacity Planning

• Predictability for stakeholders. A sprint commitment lets the wider organization plan around the team.
• Team focus. Knowing the sprint scope upfront produces a coherent picture of what success looks like.
• Forcing function for refinement. Capacity planning surfaces undersized or oversized stories before commitment.
• Sprint goal coherence. A team that knows its capacity can construct a sprint around a goal, not just a list.

How Capacity Planning Goes Wrong

• Commitment becomes contract. The forecast hardens into a deadline. Mid-sprint, the team padds estimates defensively or pushes work to look productive.
• Capacity estimates are optimistic. Teams systematically over-commit. Most sprints either miss commitment or descope quietly.
• Inflexibility. A team committed to specific items resists pivoting even when the right move is obvious mid-sprint.
• Encourages parallel work. If 30 points are committed, the team may start many items at once to "fit" — undermining flow.

The Case for Pull-Based Scheduling

• Honest about uncertainty. The team commits to doing the next thing well, not to predicting how much will fit.
• WIP limits enforce focus. Pulling only when capacity is free naturally produces lower work-in-progress.
• Encourages finishing. When you can't start a new item until you finish the old one, the team's bias shifts toward completion.
• Naturally adapts to reality. If a story turns out larger than expected, the team simply finishes it without dragging an artificial commitment along.

How Pull-Based Goes Wrong

• No forecast for stakeholders. "We'll do the next thing" is honest but doesn't help a stakeholder plan a release.
• Loss of sprint goal coherence. Without a planning step, the work that gets done may not coalesce into any meaningful sprint-level outcome.
• Refinement pressure drops. Without capacity planning to force the question of "is this ready?", stories may enter work half-baked.
• Drift to feature-factory mode. Pulling continuously can become shipping continuously without checking whether any of it is moving outcomes.

The Synthesis

Most healthy teams converge on a hybrid:

• A loose capacity estimate at sprint start — enough to give stakeholders a directional read, not a hard commitment.
• WIP limits during the sprint — pull-based discipline at the work level.
• A sprint goal as the anchor — what the team is trying to accomplish, not what the team committed to deliver.
• Probabilistic forecasting for longer horizons — Monte Carlo simulations from throughput history rather than additive point estimates.

This stance is honest about uncertainty (you can't know exactly how much fits), preserves coordination (stakeholders get directional answers), and operates with pull discipline at the team level. It works.

The Underlying Question

This debate is really about where the stakeholder pressure lands. Capacity planning compresses uncertainty into a commitment the team carries. Pull-based scheduling forces the uncertainty back upstream — stakeholders have to plan with probability ranges instead of single-point estimates. Neither approach reduces the uncertainty itself; they just decide who pays the cognitive cost.

Teams that have credibility with their stakeholders can afford to push back upstream. Teams without that credibility often need the ritual of capacity planning to demonstrate that they are taking the forecast seriously — even when the forecast is rough.

Coaching Tips

Measure commitment accuracy.

Teams that consistently miss commitment are not planning honestly. Surface the gap and reframe commitment as a forecast.

Add WIP limits to a Scrum team.

Pull discipline at the work level coexists with capacity planning at the sprint level. The two are not exclusive.

Reframe commitment as forecast.

"We're forecasting this sprint will contain about X items" instead of "we commit to delivering X items." The vocabulary shift changes the stakeholder relationship.

Add a sprint goal to Kanban teams.

Pull-based scheduling without a goal is drift. The sprint goal answers "what is this all for?" regardless of how the work flows.

Use Monte Carlo for long horizons.

"85% likely by July 15" beats "we'll finish in two more sprints" for honesty and decision usefulness.

Build forecast credibility upstream.

Stakeholders give teams more freedom on commitment when they trust the team's forecasts. Earn that credibility before pushing uncertainty back to them.

Summary

Capacity planning and pull-based scheduling solve different parts of the same problem. The team needs to know what it's trying to do (the goal), the work needs to flow without piling up (WIP limits), and stakeholders need a directional sense of when things will be done (forecasting). Healthy teams use all three. The debate matters most when one of them is missing — capacity planning without a goal is bureaucratic; pull-based scheduling without forecasting is opaque; either approach without WIP limits is dysfunctional.

Back to The Great Agile Debates