Backlog Commitment Review¶

Recurring review ritual — instantiates Overcommitment Prevention

Sorts a backlog into accepted commitments, live requests, candidates, deferred, and cancelled — so a queue of ideas is never mistaken for a stack of promises.

A backlog is where "maybe" quietly turns into "yes." Backlog Commitment Review is the recurring working session that walks a backlog item by item and re-labels each one — accepted commitment, live request, candidate, deferred, or cancelled — so the pile stops being an undifferentiated list of "things we're doing." Its one distinguishing job is to separate what has actually been promised, and to whom, from what is merely wished, queued, or dead. It sets no limit and models no capacity; it makes the true commitment count legible by draining ambiguity out of the queue, so the rest of the machinery has an honest ledger to work from.

Example¶

A product engineering team's tracker holds ~600 items, and half the company treats "it's in the backlog" as "it's coming." In the review, the team walks each epic and assigns exactly one status. Forty turn out to be genuine accepted commitments — a customer was given a date, or it sits in the signed roadmap; roughly 120 are live requests still under consideration; the rest are candidates, deferred, or quietly cancelled. Two things surface. A VP learns that three "promised" features were actually stale candidate tickets nobody owned — no promise ever existed. And one truly promised integration was buried, unowned, three quarters deep in the pile. The review adds no capacity; it reveals that the team carries 40 real promises, not 600, and drags the one silently-at-risk obligation into the light.

How it works¶

Every item gets exactly one commitment status, and "accepted commitment" is a claim that must be evidenced — a named stakeholder, a stated date or scope, an owner. Absence of evidence downgrades an item to candidate rather than letting it coast as an implied promise. The walk is re-run on a cadence so the entropy of new tickets and aging promises is swept regularly, keeping the backlog's promise/option boundary sharp instead of letting it blur back.^[1]

Tuning parameters¶

Classification taxonomy — how many status buckets exist (coarse committed/not versus fine-grained). More buckets capture nuance but slow the walk and invite disputes.
Evidence bar for "committed" — how much proof an item needs to count as a promise. A high bar shrinks the promise count but risks demoting real soft commitments to options.
Cadence and scope — whole backlog each time versus a rolling slice; frequency traded against review fatigue.
Who is in the room — just the team, or the stakeholders who made the promises. More voices means fewer disputed reclassifications later, but a heavier meeting.
Stale-item default — auto-expire untouched items to deferred/cancelled, or keep everything. Aggressive expiry keeps the backlog honest but can silently drop real work.

When it helps, and when it misleads¶

Its strength is closing the most common path to overcommitment: a wish list read as a promise list. Regular reclassification stops "maybe" from becoming an invisible "yes," and it catches the inverse — a real obligation hiding among options. But it is only hygiene: it tells you what you have promised, not whether you can deliver it. A team can leave with a spotless ledger of commitments it still cannot meet. The classic misuse is status-theater — a ritual where everything stays "in progress," nothing is ever demoted, and the backlog keeps growing while looking groomed. The discipline that guards against it is forcing net reduction or explicit deferral each pass: a review that never cancels anything is not classifying, it is accumulating.

How it implements the components¶

Backlog Commitment Review realizes the queue-hygiene side of the archetype — making promises visible, not deciding or limiting them:

backlog_and_queue_visibility — its output is a backlog where waiting, proposed, deferred, and partially-promised work is finally visible as distinct states.
demand_intake_queue — raw demand entering the backlog is sorted here into queue versus commitment, so the intake queue stops silently converting into promises.
commitment_ledger — every item tagged accepted commitment is exactly what populates the ledger of real promises.

It does not model capacity, track load over time, or enforce a cap — the monitoring loop belongs to Commitment Burndown Review, the live display to Capacity Dashboard, and any limit to Commitment Budget.

Instantiates: Overcommitment Prevention — it supplies the clean commitment ledger the rest of the appraisal counts against.
Sibling mechanisms: Commitment Burndown Review · Capacity Dashboard · Commitment Budget · Intake Capacity Checklist · Portfolio Intake Gate · Calendar Capacity Audit · Budget Encumbrance Control · Renegotiation Notice Protocol · Sales Capacity Alignment Review · Work-in-Progress Cap

Notes¶

Reclassification only holds if it has teeth. If a demoted item silently creeps back to "committed" next week — pushed by the same stakeholder pressure that inflated the backlog — the review degrades to busywork. Pair each status change with a named owner (via Intake Capacity Checklist) so the label sticks.

References¶

[1] The Scrum Guide dropped the word commitment for the sprint backlog in favor of forecast, precisely to stop a plan from being read as a promise. Backlog Commitment Review runs that same distinction across the whole backlog, not just a sprint. ↩