Every team has one. The engineer who built the payments integration three years ago, who knows why the retry logic looks the way it does, who reviews every migration that touches the billing schema. Nobody calls her a single point of failure in the planning meeting. But when she hands in her notice — or starts parental leave, or simply takes the three weeks she is owed — the release plan changes in a way no Jira field records.

Engineers have a name for this: the bus factor — the number of people who would have to be hit by a bus (or, more cheerfully, win the lottery) before critical work stalls. A bus factor of one means a single calendar entry stands between your committed release date and a very different conversation with your stakeholders.

Your confidence vote already knew who owns what

Here is the part most post-mortems get wrong: the team didn’t misjudge. When your teams voted confidence on the committed date at PI planning, that vote was expert engineering judgment. The room knew precisely who owns the payments module, how deep that knowledge runs, and what losing her for three weeks would mean. The vote was right on the day it was taken.

What the vote could not do is stay current on its own. A confidence vote is a snapshot, and the three things that erode a committed release date all go to work after the hands go down. The bus factor is the sharpest edge of the third one — capacity. On paper, one person out of eight is about 12% of your capacity. With a bus factor of one, it isn’t. Every story that needs her hands, her review, or her sign-off queues behind an empty chair, and a capacity change starts behaving like a dependency problem: the workstream sitting on your critical path idles while overall velocity looks perfectly healthy.

Why the plan doesn’t flinch

That is what makes key-person risk so quiet. The sprint board stays busy — the team picks up other work, sprint spillover stays modest, the burndown looks fine. The one epic that actually gates the release is the thing slipping, and a static plan with a typed-in date has no way to say so. Add the usual rescue instinct — backfill her, borrow a contractor from another team — and Brooks’s Law makes the late release later: onboarding consumes the very people who are left.

Most teams discover the real cost in week six, in a status meeting, when the slack is already gone.

Make the absence show up in days

The fix is not a better plan on planning day — it is a forecast that reacts when reality changes. Advanced Release Planning treats capacity as a live input to the committed date, not a number set once. Record the absence — leave, a resignation date, an incident rotation — and the Monte Carlo engine re-forecasts the release from your team’s real throughput and availability, then shows the movement in days against the committed date and its 50/85/95% confidence band. June 7 at 85% on Monday; June 16 at 85% the day the leave lands. Not a red flag in week six — a number in week one, while you can still act on it.

And acting is a renegotiation, not a confession. Pull scope back across the cut-line. Resequence so the gated epic finishes before the leave begins. Start pairing now, so the knowledge stops living in one head. The team still owns every assumption — whose capacity is in, which throughput window to trust, what is actually in scope. The app just does the arithmetic at Monte Carlo scale and keeps it current, so the confidence vote your engineers gave stays live instead of aging into folklore. (See how capacity change tracking works in the docs.)

Raise the bus factor — and track it in the meantime

The durable fix for a bus factor of one is the unglamorous work: pairing, documentation, rotating ownership. Every good engineering leader knows this, and it is a quarter-long investment that is hard to fund on a hunch. A forecast that prices the risk in days changes that conversation too: “if she leaves and nothing else changes, the date moves nine days” is a business case, not a vibe.

Until then, don’t let one person’s calendar be the invisible axis of your release. Track capacity — alongside scope and dependencies — against the date you committed to, and renegotiate before you slip, not after.

See what a capacity change really costs your next release — run Advanced Release Planning on your next Fix Version, free for 30 days. It Runs on Atlassian, so your Jira data never leaves Atlassian.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio