Sprint Capacity Rule¶
Commitment rule — instantiates Work-in-Progress Limiting
Caps the work a team may commit to active within a fixed iteration, sized to what it has recently finished — so taking on more means first dropping something.
A Sprint Capacity Rule caps how much work a team may hold as committed-and-active inside a single time-boxed iteration, and sizes that cap to the team's recent completed throughput rather than to optimism or demand. Its defining move is the time box: the limit is set at planning, frozen for the iteration, and reset at the next one. Within the box the commitment is a closed set — accepting new work mid-iteration is possible only by explicitly removing something already committed. That distinguishes it from a continuously-running cap (a token pool, a concurrency limit) that holds at every instant; the sprint rule holds over a period and deliberately couples the WIP decision to a planning rhythm.
Example¶
A product team runs two-week sprints and has finished roughly 30 story points per sprint over the last several, give or take. At planning they pull stories from the backlog until committed points reach about 30, then stop — that ceiling is the cap. Midway through, a stakeholder asks for an urgent story worth ~8 points. The rule forces the trade out into the open: for it to enter, something worth at least 8 points must leave the sprint, and the swap is recorded rather than absorbed silently.
The quiet discipline is sizing to finished work, not started work. A team that completed 30 last time does not commit to 45 this time just because the backlog is deep and the demand is loud. The cap is a memory of what the system actually delivers, held up against what everyone wishes it would.
How it works¶
- Size to completion, not appetite. The cap equals recent finished throughput — last iteration, or a running average — so the number is empirical rather than aspirational.
- Normalize the units first. Work is sized (points, counts, t-shirt sizes) so "how much" is comparable across heterogeneous items; otherwise the cap is counting apples against oranges.
- Freeze the set for the box. Once committed, the active set is closed; an addition requires a matching removal — a one-in, one-out swap made explicit.
- Reconcile at the boundary. Committed-versus-completed at iteration end becomes the input to the next cap.
Tuning parameters¶
- Iteration length — shorter boxes re-plan more often (responsive, more ceremony); longer boxes cut overhead but let a mis-sized commitment run longer before it self-corrects.
- Sizing basis — last iteration alone ("yesterday's weather"), a rolling average, or a figure adjusted for known absences. Simpler bases are robust; richer ones chase a precision that variance may swamp.
- Commitment buffer — how much slack below raw throughput to reserve for the unplanned. Zero buffer maximizes utilization but guarantees spillover on any surprise.
- Mid-iteration swap policy — strict one-in-one-out versus a small reserve held for interrupts. Stricter protects focus; looser accommodates real urgency at the cost of the box's meaning.
When it helps, and when it misleads¶
Its strength is converting "we'll try to do all of it" into a bounded, empirical commitment, and making the price of any new mid-flight request explicit — something must give. Sizing to finished work is a simple, robust heuristic often called Yesterday's Weather: use the amount actually completed last iteration as the forecast for the next.[n1]
Its failure modes cluster around the number being soft. Points are gameable — they can inflate so "velocity" rises without more real output, flattering the cap while quietly eroding its own basis. A cap treated as a quota to fill rather than a ceiling not to exceed recreates the overcommitment it was meant to end. And because it governs a period, it does nothing about churn within a day: a team can still thrash across ten started stories under a 30-point cap unless a running limit is added alongside it. The classic misuse is inflating estimates after the fact so a fixed output "meets" the commitment — running the metric backwards. The discipline is to size to completed work, keep the units stable over time, and treat the cap as a ceiling that a Throughput-Based Limit Review periodically re-checks.
How it implements the components¶
Sprint Capacity Rule fills the cap-and-sizing components, scoped to an iteration:
wip_limit— the per-iteration commitment ceiling is the WIP limit, bounded to a time box.capacity_basis— recent completed throughput (velocity) is the credible basis that keeps the number from being a wish.work_size_normalization— sizing items into comparable units is what lets the cap meaningfully count "how much," not just "how many."
It does not enforce the limit continuously or at the instant of starting (admission_control_rule, pull_replenishment_signal → Pull Replenishment Signal), name an owner across teams (owner_or_steward → Team Workload Cap), or run the recalibration ritual (review_and_adjustment_cadence → Throughput-Based Limit Review).
Related¶
- Instantiates: Work-in-Progress Limiting — a time-boxed form of the cap, coupled to a planning cadence.
- Sibling mechanisms: Team Workload Cap · Throughput-Based Limit Review · Work Slot Token · Kanban WIP Limit · Active Case Cap · Concurrency Limit · Project Portfolio Limit · Blocked Work Swarming · Pull Replenishment Signal
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Sprint Capacity Rule operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it caps the work a team may commit to active within a fixed iteration, sized to what it has recently finished — so taking on more means first dropping something.
Independent corroboration: The frozen evidence defines Sprint Capacity Rule as 'Caps the work a team may commit to active within a fixed iteration, sized to what it has recently finished — so taking on more means first dropping something', so its operative form is Rule, Policy & Commitment.
Nearest alternative: Decision, Gate & Allocation — Sprint Capacity Rule includes features of a case-specific gate, selection, routing, prioritization, or resource disposition, but its defining operation is a standing rule, threshold, contractual commitment, or policy constraint governing future conduct.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Limiting iteration commitments to demonstrated throughput is agile work-management practice.
Related originating lineages:
- Computer Science & Software Engineering — Software teams institutionalized sprint capacity.
- Operations Research — Work-in-process limits protect flow.
- Psychology — Bounded commitments reduce overload and planning fallacy.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: caps the work a team may commit to active within a fixed iteration, sized to what it has recently finished — so taking on more means first dropping something.
Review resolution: The blind reviewers agree that organizational_management is the primary origin and differ only on alternate origin disagreement, domain reach disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain single_lineage because the combined evidence shows one traceable formative lineage. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=false preserves the affirmative synthesis judgment where either reviewer identified one.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The sprint cap governs a period, not an instant: it bounds what may be committed across the iteration but not how many items are churning at any given moment. When intra-iteration thrash is the real problem, pair it with a running limit such as a Work Slot Token pool or a per-stage cap.
[n1] Yesterday's Weather is the agile planning heuristic of using the amount of work a team actually completed in the previous iteration as its commitment for the next — an empirical, deliberately unglamorous alternative to forecasting capacity from ambition. ↩