Planning day went well. The team walked through the scope, sized the work against real throughput, and when the room did its confidence vote, the hands came up as a solid four out of five. You left with a committed release date you could actually defend.
Three weeks later, none of that is quite true anymore. Your strongest backend engineer is buried in a Sev-1 incident and won’t resurface for a sprint. A second developer started a leave nobody saw coming. A third got quietly borrowed by a customer escalation. Nobody quit. Nobody is slacking. But the team that cast that vote is not the team shipping the release — and the committed date is already moving, even though no one has said so out loud. That slow bleed is capacity risk.
It’s the quietest of the three ways a committed date comes apart, because it hides inside people’s calendars instead of on the board.
Capacity risk is the third post-commitment killer
A committed release date rarely breaks in one dramatic moment. It erodes. As the pillar on the three things that erode a committed release date lays out, two of the culprits get most of the airtime: scope quietly creeping past what you agreed to, and a dependency surfacing far too late to absorb. Capacity is the third — and the one teams are least equipped to catch, because most agile capacity planning stops the day planning ends.
Planned time off isn’t capacity risk. The unplanned kind is.
To be fair, some capacity loss is entirely knowable. Vacations, public holidays, a parental leave already on the calendar — you can enter those up front, and good capacity planning for PTO and holidays bakes them into the forecast on day one. That isn’t the dangerous kind. Capacity risk is the loss you couldn’t schedule: the incident that swallows a sprint, the reassignment that lands mid-increment, the resignation you hear about on a Tuesday. It arrives after the vote — which is exactly what makes it a threat to the date.
The vote wasn’t wrong — it was a snapshot
Here’s the part worth being careful about. When your team held up four fingers on planning day, that wasn’t optimism or gut feel. It was expert engineering judgment about the capacity you actually had that day, and the judgment was sound. The trouble is that a confidence vote is a snapshot, and capacity keeps moving after the photo is taken. The team still owns the assumptions — whose availability, which throughput window, what’s in scope. What it needs is a way to keep those assumptions current without re-running planning every time a calendar shifts.
Let the forecast carry the change
Advanced Release Planning forecasts your committed date from two live inputs: your team’s real throughput and its real capacity. Its Capacity Awareness setting factors availability — throughput, work in progress, and time off — straight into a Monte Carlo simulation. So when capacity changes, you flag a developer as unavailable or adjust an allocation, and the forecast re-runs. The committed date shifts, measured in days, and the confidence band around it moves with it. A date that sat comfortably on the 85% line at planning might slide to 60% once you lose a sprint of a key contributor — and you see that drift the week it happens, not at the demo.
That one number changes the conversation. Instead of discovering the slip too late, you catch it while there’s still room to act: pull the lowest-priority scope back to the MoSCoW cut-line, resurface work that a late dependency is blocking, or renegotiate the commitment itself with leadership — on evidence, not apology. A release reads as on-track while its committed date stays on or after the P85 line; capacity risk is simply what pushes it before that line, and now you can watch it happen.
None of this replaces the team’s judgment. It’s the SAFe confidence vote, run continuously on data the team validates, rather than once on planning day. The room still decides what “committed” means and at what confidence — the tool just makes sure the number in front of them reflects the team they have this week, not the team they had at the vote.
Give your committed date a fighting chance
Capacity will change on every release you ever ship. The teams that hit their dates aren’t the ones who guessed capacity perfectly on planning day — they’re the ones who noticed the moment it shifted and renegotiated before the date slipped. Put your committed date on a live confidence band and let Advanced Release Planning track capacity risk for you, free for 30 days, right inside Jira. For the mechanics, see how capacity change tracking works — and give your next release a date that survives contact with reality.
Leave a Reply
Your email is safe with us.