Key Takeaways
- Critical chain project management pools the safety hidden inside task estimates into one visible project buffer and manages the release by buffer consumption instead of individual task dates.
- Its weak point in practice is bookkeeping, not theory: the buffer is sized once at planning, and the fever chart that tracks burn is a manually updated snapshot.
- Scope creep, late-surfacing dependencies, and capacity changes drain the buffer between updates — the chart tells you how much protection is gone, never why.
- A live 50/85/95% confidence band is the same instrument, self-updating: the gap between the P50 date and the committed date is the project buffer in calendar days, recalculated continuously from real Jira throughput and attributed by driver.
The delivery lead who read Goldratt
There is a specific kind of delivery lead who has actually read Critical Chain — not the summary, the book. She came back convinced, and she was right to be. She stripped the invisible padding out of every estimate, pooled it into one project buffer at the end of the plan, and put a fever chart on the wall: buffer consumed on one axis, chain complete on the other. Green, amber, red. For three weeks it was the sanest planning artifact the team had ever had.
Then the Wednesday update slipped to Friday. The chart was still on the wall in week nine, politely insisting the release was amber, while everyone in standup knew it was red. The instrument was sound. The instrument was also hand-cranked.
What critical chain got right
Critical chain project management starts from an observation that still stings thirty years on: single-date plans lie twice. Each task estimate carries private safety — padding you can’t total, trade, or track — and the plan built on those estimates still slips, because hidden safety gets spent invisibly. Goldratt’s fix was structural. Estimate lean, pool the safety into an explicit project buffer, place it where the whole release can draw on it, and then manage one number: how fast that buffer is burning relative to progress along the chain.
This is also where critical chain vs critical path stops being an exam question. The critical path is the longest sequence of dependent tasks, assuming people are infinitely available. The critical chain is that same walk through the plan with resource reality included — the path as your actual, finite team can execute it.
Notice what the critical chain method respects: the team’s judgment. How much buffer, where the chain runs, what belongs in scope — those are engineering decisions, made by the people who know the work. A buffer sized by the team is the same kind of artifact as a PI confidence vote: expert judgment, recorded at a moment in time.
Where the fever chart falls behind
The trouble is the phrase “recorded at a moment in time.” The buffer is sized once, at planning, against the scope and the roster as they stood that day. The fever chart only moves when someone updates it. And between updates, the three things that erode a committed release date keep working: scope arrives that the chain never priced, a dependency surfaces and quietly re-routes the chain itself, capacity shifts as people are borrowed away. The behaviors Goldratt designed the buffer to absorb — student syndrome and Parkinson’s Law — burn it silently from the inside.
So the Friday review reads “buffer 40% consumed” — measured against a plan that no longer exists. The chart can tell you protection is gone. It cannot tell you which of the three killers took it, or what it did to the date you promised.
A buffer that watches itself
In Release Management, Roadmaps & Product Portfolio for Jira, the release date isn’t a typed-in date — it’s a band. Monte Carlo simulation runs on the team’s actual Jira throughput and places three dates on the calendar: 50%, 85%, 95%. The team commits at the level that matches the cost of a miss — and from that moment, the gap between the P50 date and the committed date is the project buffer, in calendar days, visible to everyone on the plan.
Because the band is recalculated continuously from observed throughput, buffer management stops being bookkeeping. A date committed at 85% that has drifted to 62% is the fever chart’s red zone — computed for you, current as of today, no spreadsheet. Late starts and expanding tasks lower observed throughput and move the band; so does the scope that arrived last Tuesday and the engineer leaving next sprint. And unlike the wall chart, the movement is attributed: scope added four days, a late dependency added three, capacity change added two. Burn, with a cause.
Manage by exception, renegotiate before the slip
Critical chain’s best habit was managing by exception — leave the team alone while the buffer holds, act when burn crosses the line. A live band keeps that habit and sharpens it. While the committed date sits at or above 85%, nobody touches the plan. When it drifts, the conversation starts before the date slips, and it starts specific: nine days of protection are gone, here is where they went — do we trim scope, resolve the dependency, or move the date deliberately?
That is the conversation Goldratt wanted teams to have. He just asked them to hand-crank the math.
Run your release on a buffer that updates itself
Keep the discipline of critical chain project management — the pooled buffer, the burn threshold, management by exception — and retire the manual fever chart. Try Release Management, Roadmaps & Product Portfolio for Jira free on the Atlassian Marketplace, and see how the confidence band works in the docs.
Leave a Reply
Your email is safe with us.