Most release managers can produce their release management process on request. It is usually a diagram: intake, planning, commitment, build, hardening, readiness review, go/no-go, deploy, retrospective. Boxes, arrows, owners, exit criteria. Someone spent a quarter getting it agreed, and it was worth every hour — it ended the arguments about who signs off on what.
Then a stakeholder asks the only question that ever really matters: are we still hitting the 14th?
And the process goes quiet. It can tell you exactly which gate you are standing at. It cannot tell you whether the date you committed to at gate two is still the date you will hit at gate seven.
A process is a sequence. A release date is a forecast.
This is not a criticism of the process. It is a description of what a process is for. A release management process defines order: what must happen before a release ships, who owns each step, and what finished looks like at each boundary. That is genuinely valuable, and no amount of forecasting replaces it.
But order is not timing. Knowing that code freeze precedes the readiness review tells you nothing about when you will reach code freeze. The date lives somewhere else entirely — in a commitment your team made once, at one specific moment, near the front of the diagram.
That commitment is not a guess. When a team runs a confidence vote — the SAFe fist of five, or any equivalent show of hands — what it produces is expert engineering judgment about work those engineers understand better than anyone else in the building. They know which parts are well-trodden and which are new. They know what integration usually costs them. They own the assumptions: which throughput window is representative, whose capacity is genuinely available, what is actually in scope.
The trouble is what happens next. That judgment gets recorded once and then carried forward as a fact. A confidence vote is a snapshot. The process it feeds is a snapshot too. And releases do not erode at the snapshots — they erode in the weeks between them.
The erosion happens in the white space between gates
Map the three things that erode a release date onto any standard process diagram and every one of them enters in the gaps between two boxes, not inside them.
- Scope creep arrives between commitment and freeze. Your process almost certainly has a change gate for this, and it works — nothing gets in unauthorised. But a board approves a change, not a new date. Six approved changes produce six approvals in the minutes, not the eleven days they collectively cost.
- Dependencies surface late, usually somewhere between build and integration. Your process assigns owners and handoffs, but a RACI chart cannot carry a promised date from a team that is not in your process at all — and it certainly cannot carry your position in their queue.
- Capacity changes are never a process event. Nobody files a gate transition when two engineers are pulled onto an incident, when a new hire ramps slower than hoped, or when the roster running the release quietly stops being the roster the commitment was priced for.
Each of these moves the real date. None of them trips a step in the process, because the process watches for completed work, not for changed conditions.
What a gate review can — and cannot — tell you
Sit in a typical readiness review and you will be handed status: percent complete, open defect count, tickets remaining, a colour per workstream. All true. All useful. None of it answers when.
Status describes where the work is. It does not project where the work is going, because projecting needs two things a status report does not contain: how much work is genuinely left, and how fast this team actually completes work — measured from its own history rather than assumed. Run those together across enough simulated outcomes and you stop producing a single hopeful date and start producing a range: a 50% date, an 85% date, a 95% date.
That range is what turns a gate from a checkpoint into a decision point. “We are 78% complete” invites a nod. “The committed date now sits nine days past our 85% confidence date, six of them from scope added since the vote” invites a decision — while there is still room to make one. That is the shape of release planning in Jira when the forecast is continuous: a committed date carrying a live confidence band, re-forecast from the team’s own throughput, with the gap reported in days and attributed to what moved it. The mechanics are documented in Release Process Gates and the Committed Date.
Give every gate you already have a number that moves
You do not need a new process. You need one number added to the one you have.
- Commit at a stated confidence. Not “the 14th,” but “the 14th, and we are 85% confident of it.” The vote already contained that judgment. Write it down.
- Read the band at the gates you already hold. Your process convenes people at defined moments anyway. Each one is a free checkpoint — no new meeting required.
- Report drift in days, with a cause. Not “amber.” Rather: eleven days of drift, seven from scope admitted since the baseline, four from a dependency that landed late.
- Renegotiate at a gate, not at the deadline. This is the step almost no process has. When drift breaches the band, the honest move is to renegotiate before you slip — trade scope, move the date once and deliberately, or accept a lower confidence with everyone’s eyes open.
The process still tells you what happens next. Now it also tells you when — and, more usefully, the moment that answer changed.
The team’s judgment was never the weak link. The weak link is that nobody re-runs the arithmetic after the conditions move. Release Management, Roadmaps & Product Portfolio for Jira keeps a committed date and its confidence band live between every gate in your release management process — so the conversation happens at a checkpoint instead of at the deadline.
Key takeaways
- A release management process defines order — gates, owners, handoffs, sign-offs. It answers “what happens next,” never “when.”
- The committed date is set once, at a confidence vote that captures the team’s expert engineering judgment. Nothing in a standard process re-reads it afterwards.
- Scope creep, late dependencies and capacity changes all enter between gates, where no process step is watching.
- Status tells you where the work is. A confidence band tells you where it is going, in days, at 50%, 85% and 95%.
- Add one live number to the gates you already run, and renegotiation becomes a scheduled decision instead of a late apology.
Frequently asked questions
What are the stages of a release management process?
Most look broadly alike: intake and prioritisation, planning and commitment, build, integration and hardening, readiness review, go/no-go, deployment, and a post-release retrospective. The exact boxes matter less than the boundaries between them, because the boundaries are where a committed date quietly moves without anyone recording it. Forecasting the release continuously in Jira gives each of those boundaries a current date and confidence level to read.
Does a good release management process guarantee an on-time release?
No, and it is not meant to. A process governs how decisions get made, who is accountable, and what quality bar applies — it does not govern how long work takes. A mature process makes a slip visible earlier and better documented, but only a live forecast against the team’s actual throughput tells you the slip is coming while there is still time to trade scope or move the date deliberately.
1 Comment
Leave your reply.