Key Takeaways
- Contingency reserve covers risks the team identified and priced. Management reserve is held outside the baseline for the ones nobody could name.
- Both are priced once, at the commitment, and then spent silently by scope creep, late dependencies, and capacity change.
- “Do we still have buffer?” is a forecasting question. Remaining reserve is the distance between the committed date and where delivery forecasts today, at the confidence level you committed at.
- Read it in days against a live 50/85/95% confidence band, and renegotiate before the date moves rather than after.
Six weeks after the planning event, someone asks the question that changes the temperature of the room. Do we still have buffer?
Everyone knows there was some. The plan had contingency in it, a real number, argued over and agreed. What nobody can say is what that number is now. So the conversation turns into archaeology: who added what, whose two-day estimate quietly became five, whether the integration work was inside the reserve or outside it. Forty minutes later the room has a feeling, not a figure.
Two reserves, two owners
Classic project management splits schedule reserve in two, and the split is worth keeping.
Contingency reserve is time set aside for risks you identified: the integration you know is messy, the vendor API with a history of slipping, the regression suite that always finds something. It sits inside the schedule baseline. The delivery team owns it and can spend it without escalating.
Management reserve is time held outside the baseline for what nobody could name in advance. The sponsor or the portfolio owns it, and it is released by an explicit decision rather than by drawdown.
The distinction matters because the two are spent so differently. Management reserve is only ever spent on purpose; somebody has to ask for it. Contingency drains quietly, a day here and two days there, no meeting required. Which is exactly why it is the one nobody can account for six weeks in.
The vote priced it correctly. The weeks after moved it.
It is tempting to conclude the team under-reserved. Usually they did not.
A commitment confidence vote is expert engineering judgment. The people who cast it knew which risks deserved a reserve, which throughput window actually described their team, and what was really in scope. That number was good on the day it was made. What a number written on a planning day cannot do is stay true through the eleven weeks that follow it.
Three things spend contingency after the vote without asking permission: scope arriving one reasonable request at a time, dependencies surfacing later than anyone assumed, and capacity changing under the plan. They are the three things that erode a committed release date, and each of them is paid for out of reserve first, silently, long before it shows up as a slipped date.
By the time the date moves, the reserve has been gone for weeks.
“Do we still have buffer?” is a forecasting question
The reason the archaeology never works is that reserve is not a bucket you can go and look in. It is a relationship: the distance between the date you committed to and the date your delivery now forecasts, at the confidence level you committed at.
Which makes it readable. If you committed at 85% confidence and today’s forecast puts the 85% date four days past the committed date, you are four days overdrawn, whatever the planning spreadsheet still says the reserve was. If the 85% date lands nine days early, that is your remaining contingency, in days, right now.
Critical chain project management had this instinct decades ago: watch buffer consumption, not task dates. The missing piece was never the theory, it was a number that updates itself. The same is true of the hardening sprint, which is simply the place where a visible chunk of that reserve physically sits.
Keeping the reserve live
Advanced Release Planning re-runs a Monte Carlo forecast over your team’s actual Jira throughput and reports a committed date with a 50/85/95% confidence band beside it. The team still owns the assumptions: which throughput window to trust, whose capacity counts, what is in scope. The app does the arithmetic at simulation scale and keeps it current.
So when scope is added, a dependency surfaces, or someone rolls off the team, it shows up as days moved against the committed date in the same week it happens. Reserve stops being a memory and becomes a reading. See how remaining reserve is read in the docs.
Four habits that make it stick
- Name the reserve at the vote. Record which risks it covers and which confidence level you committed at. Choosing 85% is itself a reserve decision.
- Read it in days, not percent. Days are the unit a stakeholder can act on.
- Set a renegotiation trigger. When the date at your committed confidence level crosses the committed date, you talk about scope. Not at the end.
- Keep management reserve a decision. If it is being drawn down quietly, it is not management reserve any more.
The team’s judgment on planning day was the hard part, and it was right. Keeping it true for the next eleven weeks is arithmetic, and arithmetic is what software is for.
See what your release has left, in days, on a live confidence band in Jira.
Leave a Reply
Your email is safe with us.