Commitment Burndown Review¶

Recurring reforecasting review — instantiates Overcommitment Prevention

Periodically reconciles what was promised against what has been completed, cancelled, deferred, and newly accepted — so the true commitment load is tracked, not assumed.

Commitment Burndown Review treats the commitment ledger like a burndown: each cycle it books what closed, what was cancelled or deferred, and what was newly accepted, then re-forecasts whether the remaining load still fits reality. Its distinguishing idea is watching the commitment set over time and against drifting assumptions — its unit of attention is the trend (are we accepting faster than we are closing?), not the classification of any single item (Backlog Commitment Review) or the instantaneous display (Capacity Dashboard). It is the mechanism that catches the slow overcommitment no single decision causes.

Example¶

A consultancy's engagement portfolio looks fine each week in isolation, but the burndown review plots it. Over six weeks the team closed 4 deliverables, cancelled 1, deferred 2 — and accepted 11. The line is climbing, not burning down. The review also flags an assumption on the register that has quietly gone stale: two senior consultants were assumed available in Q3, but one is now locked into a fixed client extension. Re-forecasting with the corrected assumption, the remaining load overruns capacity by ≈5 weeks. No single new engagement was unreasonable; the rate — and a broken assumption — were. The output is a trend and a reforecast that trigger an intake freeze, not a reclassification of any one item.

How it works¶

The signature is flow accounting plus reforecast. Each period it records the accepted, completed, cancelled, and deferred deltas against the ledger and plots the promised-load remaining. It rechecks the assumption register for drift, reforecasts whether the current set still fits, and raises a signal when the accept-rate outruns the close-rate or a load-bearing assumption breaks. This is what keeps the ledger alive rather than a stale planning snapshot.^[1]

Tuning parameters¶

Cadence — weekly versus monthly. Frequent review catches drift early but costs attention; sparse review lets load accumulate between looks.
Load metric — count of commitments, effort remaining, or obligation-weighted. Effort-weighting is truer but harder; counts are cheap but hide big items.
Reforecast horizon — how far ahead each review projects. Short horizons are reliable but miss cliffs; long ones compound estimate error.
Assumption-drift sensitivity — how aggressively stale assumptions are challenged. High sensitivity catches breaks but generates churn.
Trigger threshold — what accept-versus-close gap raises the alarm. Tight triggers act early; loose ones avoid false alarms but react late.

When it helps, and when it misleads¶

Its strength is catching the slow overcommitment — a load that creeps up because acceptance quietly outpaces completion — and forcing assumptions to be re-examined instead of trusted forever. Its limit is that it is retrospective: it tells you the trend is bad only after several cycles, so it is a lagging guard, weaker than a hard limit at the intake boundary. The classic misuse is running it as a reporting ritual that plots the line but never triggers an intake freeze — measurement without a stop rule. The discipline is to pre-wire the trend to an action (freeze intake, escalate) so the reforecast actually changes behavior rather than just narrating decline.

How it implements the components¶

Commitment Burndown Review realizes the monitoring-and-reforecast side of the archetype:

commitment_ledger — it reconciles and refreshes the ledger each cycle, keeping it a live record rather than a stale plan.
monitoring_and_reforecasting_loop — the periodic loop that rechecks whether the current commitment set still fits reality and reforecasts when it does not.
assumption_register — the log of load-bearing assumptions the review rechecks for drift each cycle.

It tracks the ledger over time but does not classify raw backlog items (Backlog Commitment Review), display live signals (Capacity Dashboard), or set the cap it reports against (Commitment Budget).

Instantiates: Overcommitment Prevention — it keeps the commitment ledger honest over time so overload is caught while it is still fixable.
Consumes: Backlog Commitment Review supplies the classified commitment ledger it reconciles each cycle.
Sibling mechanisms: Backlog Commitment Review · Capacity Dashboard · Commitment Budget · Portfolio Intake Gate · Intake Capacity Checklist · Calendar Capacity Audit · Budget Encumbrance Control · Renegotiation Notice Protocol · Sales Capacity Alignment Review · Work-in-Progress Cap

References¶

[1] A burndown chart in Scrum plots remaining work against time within a sprint. Commitment Burndown Review borrows the shape but applies it to the whole commitment ledger across periods: the tracked quantity is promised obligation, and a line that fails to fall — or climbs — is the signal that acceptance is outrunning delivery. ↩