The quarterly review had one slide everyone remembers. Version 4.2, committed for March 31, was now April 30 — and the slide didn’t say “late.” It said “re-baselined.” Heads nodded, the status column stayed green, and the meeting moved on. Three months later the same slide said June 15, and nobody in the room could tell you which week the release actually started slipping, or why.
A schedule baseline is one of the oldest, most sensible ideas in project management: an approved reference schedule, fixed at the moment of commitment, that everything afterward is measured against. Its whole job is variance detection. A baseline doesn’t make anyone faster — it makes drift visible. That’s the value, and it’s real.
The plan with no memory
The failure mode isn’t having a baseline. It’s what happens when the variance gets embarrassing: the baseline moves. Re-baseline every quarter and variance always reads near zero, status always reads green, and the plan is never wrong — because the plan has no memory. Each reset ratifies the slip after the fact and deletes the evidence of how it happened. The release ends up “on track” and four months late, and both statements are technically true.
The vote was right. The weeks after moved.
Here’s what the re-baseline ritual gets wrong, and it isn’t the team. The original commitment was not a guess. At PI planning, the team took a confidence vote — expert engineering judgment applied to evidence the team itself validated: which throughput window reflects how they really deliver, whose capacity is actually available, what is genuinely in scope. That vote was right on the day it was taken.
What moved the date came afterward: the three things that erode a committed release date — scope creep, dependencies that surface late, and capacity changes. They arrive a few days at a time, in between reviews. A static baseline can’t watch them accumulate; it can only be compared against occasionally, and then blamed for what the comparison shows. So renegotiation happens after the slip, which is exactly backwards.
A baseline that reads back
Advanced Release Planning for Jira treats the committed date itself as the baseline — and keeps it live. The team’s commitment is recorded with its confidence band: 50%, 85%, and 95% dates forecast by Monte Carlo simulation over the team’s actual Jira throughput. The team still owns every assumption behind the number — the throughput window, the capacity, the scope. The app’s contribution is arithmetic at a scale no quarterly spreadsheet re-run can match: thousands of simulations, recalculated the moment the underlying data changes.
Variance stops being a quarterly confession and becomes a live reading. The committed date holds still; the forecast moves; the gap between them is measured in days and attributed to a cause — the burn-up’s scope line stepping up, a dependency landing on the critical path, capacity dropping below what the vote assumed. That attribution is what tells you what actually moves a committed release date, while it’s moving. When the committed date sits at or after the 85% line, the release is on-track. When it drifts between 50% and 85%, that’s the amber moment: renegotiate scope now, while there’s still slack to trade. The date hasn’t moved yet. You’re defending it before it does.
When moving the date is the right call
None of this makes re-baselining a sin. Sometimes the world genuinely changes — funding shifts, priorities pivot, a partner dependency dissolves — and holding a date the evidence no longer supports helps nobody. That’s the project management triangle doing what it always does: scope, capacity, and time trading against each other, this time in the open. The rule that keeps the move honest is simple: a new baseline is a new commitment, and a commitment deserves what the first one got — a confidence vote on current evidence, at a stated confidence level, with the drift that forced the move still on the record. Move the date once, deliberately, at 85% confidence. Not quarterly, quietly, at none.
The baseline was never the problem. Asking a frozen reference and a quarterly meeting to police a fight that happens daily — that was the problem. Keep the reference; give it a pulse. (You can see how commitment tracking works in the docs.)
If your last three baselines each survived exactly one quarter, the plan isn’t unlucky — it’s unwatched. See what your current release looks like against a baseline that doesn’t blink: run Advanced Release Planning on your next Fix Version, free for 30 days.
