Rework Capacity Allocation Rule¶
Capacity allocation rule — instantiates Technical Debt Buffering and Rework Absorption
Dedicates a fixed percentage, team, budget line, maintenance lane, or recovery reserve to repayment work before new work fully consumes capacity.
A Rework Capacity Allocation Rule is a standing policy that carves a fixed, recurring share of capacity off the top for debt repayment — before new work is allowed to consume it. Twenty percent of every sprint; one engineer in five on a maintenance rotation; a permanent budget line for cleanup. Its defining property is that it is continuous and structural, not episodic: repayment is a constant background flow that runs every cycle regardless of what shipped, so debt is drawn down steadily rather than in occasional bursts. It exists because the reliable failure of good intentions is that new work expands to fill all available capacity; a standing allocation is a pre-commitment that protects a repayment lane from that expansion by construction. It turns "we'll pay it down when we can" into "a fixed slice is always paying it down."
Example¶
A consultancy runs a long-lived internal platform that every client project depends on, and for years cleanup only happened in the gaps between projects — which meant never, because there were no gaps. So engineering leadership institutes an allocation rule: 20% of every team's capacity, every sprint, is reserved for debt burndown, taken off the top before new project work is committed. It is implemented as a protected lane on the board — four of every twenty story points must be repayment items pulled from the ledger, prioritized by risk — and a team that fills all twenty with new work is out of policy.
Quarter over quarter, the effect is not dramatic in any single sprint, but the risk-weighted debt score trends steadily down because something is always being repaid. When a crunch hits and a lead is tempted to spend the 20% on the deadline, the rule is the thing that says no — the lane is reserved, and raiding it requires an explicit, visible exception rather than a quiet default. The allocation rule never schedules a special cleanup block and never reacts to a particular release; it just guarantees that a fixed fraction of the organization's effort is, always, going to repayment.
How it works¶
The rule's distinguishing logic is a protected, recurring slice of capacity:
- Reserve off the top. A fixed fraction of each cycle's capacity is allocated to repayment before new work is committed, so new work competes for what remains, not for the reserve.
- Make the burndown continuous. Repayment items are pulled every cycle from the ledger by priority, so the debt is drawn down steadily rather than waiting for a dedicated window.
- Protect the lane structurally. The allocation is a standing rule with a visible slot (a board lane, a headcount, a budget line), so spending it on new work is an exception that must be declared, not a silent default.
- Right-size against the inflow. The fraction is set relative to how fast debt is accruing, so repayment at least keeps pace with new borrowing.
Tuning parameters¶
- Allocation fraction — how large a share is reserved (10%, 20%, a whole rotation). Higher pays debt faster but slows feature delivery; lower preserves throughput but may lose to the inflow.
- Allocation unit — percentage of capacity, a dedicated person/team, or a budget line. A person-based reserve is unambiguous but coarse; a percentage is flexible but easier to erode.
- Prioritization within the lane — highest-risk-first, oldest-first, or quick-wins. Risk-first reduces danger; quick-wins build momentum and visible progress.
- Raid policy — whether and how the reserve can be borrowed against under pressure. A hard lock protects repayment but is brittle in emergencies; a logged-exception policy is flexible but erodes if overused.
- Review cadence — how often the fraction is recalibrated against the debt inflow. Frequent tuning tracks reality; rare tuning is stable but can drift out of proportion.
When it helps, and when it misleads¶
Its strength is steadiness: a standing allocation makes repayment independent of any single event, deadline, or act of will, which is exactly what the archetype means by protecting future capacity rather than "relying on informal promises." It embodies the principle that a system run at 100% utilization has no capacity to improve itself — deliberate reserved slack is what lets an organization pay down debt and adapt at all.[n1]
Its failure mode is that a percentage is the easiest reserve to quietly erode: under deadline pressure the 20% becomes 10% "just this sprint," then zero, and because nothing dramatic happens in any one cycle, no alarm sounds. The classic misuse is theater — a nominal allocation that is raided every crunch, so the policy exists on paper while repayment never actually happens. The guarding discipline is to make raids visible and exceptional (log them, review them, restore the lane deliberately), and to pair the standing allocation with an episodic Hardening Window so a burst of debt from a big transition is not left to a steady trickle that can never catch up.
How it implements the components¶
This mechanism fills the archetype's standing-repayment slice:
rework_capacity_reserve— its core: a fixed, recurring fraction of capacity fenced for repayment before new work is committed.repayment_trigger_and_burndown_plan— the continuous per-cycle pull of prioritized items from the ledger is the burndown plan, executed as ongoing policy rather than a one-off trigger.
It does NOT implement transition_phase_exception_register — it works down whatever the ledger holds, without a transition-scoped list; that register belongs to Hardening Window and Exception Expiry Timer. Its nearest twin is the Hardening Window, which reserves an episodic block; this rule reserves a continuous slice.
Related¶
- Instantiates: Technical Debt Buffering and Rework Absorption — provides the standing reserve that keeps repayment continuous.
- Consumes: Technical Debt Ledger supplies the prioritized items the lane pulls each cycle.
- Sibling mechanisms: Debt Aging Dashboard · Technical Debt Ledger · Quality-Risk Triage Rubric · Debt Ceiling Gate · Exception Expiry Timer · Feature Flag or Containment Wrapper · Hardening Window · Post-Release Rework Retrospective
Editorial Notes¶
Form Classification¶
Form family: Rule, Policy & Commitment
Rationale: Rework Capacity Allocation Rule operates as a standing rule, threshold, contractual commitment, or policy constraint governing future conduct because it dedicates a fixed percentage, team, budget line, maintenance lane, or recovery reserve to repayment work before new work fully consumes capacity.
Independent corroboration: The frozen evidence defines Rework Capacity Allocation Rule as 'Dedicates a fixed percentage, team, budget line, maintenance lane, or recovery reserve to repayment work before new work fully consumes capacity', so its operative form is Rule, Policy & Commitment.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Organizational & Management Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Protecting recurring capacity for corrective work is a resource-allocation and continuous-improvement practice.
Related originating lineages:
- Accounting & Auditing — Debt-service and reserve concepts materially motivate prior allocation to repayment.
- Computer Science & Software Engineering — Technical-debt management independently assigns iteration capacity to rework.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: dedicates a fixed percentage, team, budget line, maintenance lane, or recovery reserve to repayment work before new work fully consumes capacity.
Review resolution: Both blind reviewers agree that organizational_management is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement starts from reviewer_a’s mechanism-specific evidence: Protecting recurring capacity for corrective work is a resource-allocation and continuous-improvement practice. Reviewer A proposed alternates=accounting_auditing, computer_science, origin_mode=cross_disciplinary_synthesis, domain_reach=multi_domain, and encyclopedia_synthesis=true; reviewer B proposed alternates=systems_cybernetics, origin_mode=convergent, domain_reach=multi_domain, and encyclopedia_synthesis=true. The final record retains every independently supported alternate from either review (accounting_auditing, computer_science, systems_cybernetics) without an arbitrary cap, selects origin_mode=cross_disciplinary_synthesis to represent the combined lineage evidence, and keeps domain_reach=multi_domain and encyclopedia_synthesis=true from the more mechanism-specific assessment. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Tom DeMarco's Slack argues that an organization run at total efficiency has no reserve capacity for improvement, learning, or change. A standing rework allocation is deliberate slack aimed at debt: capacity reserved so the system can repair itself rather than only produce. ↩