Every release date has three quiet enemies. They almost never show up by name in a status meeting, and none of them announce themselves — but between them, dependencies, capacity, and scope creep are behind most of the release dates that slip. Version 2.13 of Advanced Release Planning, Roadmaps & Management for Jira closes the last of those three gaps — and it quietly changes how you plan a release.

For months the app has turned two of those forces into numbers your forecast can actually use. With 2.13, scope creep in Jira becomes the third — visible, measured, and wired straight into your probabilistic release date. Here is why that matters.

The three productivity killers

Teams rarely miss a date because they are slow. They miss because something outside the burndown moved:

• Dependencies — work that cannot start until something else finishes.
• Capacity — the people you planned around who are not actually available.
• Scope creep — the plan that keeps growing after everyone agreed it was done.

Any one of them can move a date by weeks. The problem has never been naming them — it is that most planning tools keep them invisible until it is too late to react. A roadmap drawn from the dates you typed in looks precise, but it reflects intent, not evidence. To plan with evidence, you have to measure all three. Here is how the app does it — and what 2.13 finally adds.

Killer #1: Dependencies

A single blocked hand-off can hold an entire release hostage, and the damage is rarely obvious from a board. Advanced Release Planning maps linked issues on an interactive Dependency Map and highlights the Critical Path — the longest chain of dependent work that sets your true minimum delivery time. Those links are not just a picture: they feed a dependency-aware Monte Carlo forecast, so a late upstream item shows up as risk on the date, not as a surprise at hand-off. That is the first productivity killer turned into a number.

Killer #2: Capacity

The second killer is the gap between the team on paper and the team that actually shows up. Half the team on PTO the same week, a public holiday, work in progress spilling over from last sprint — none of it appears in a story-point total, but all of it moves the date. Toggle Capacity Awareness on and the forecast blends real throughput, WIP, PTO, and holidays into the projection, and warns you when committed scope exceeds what the team can realistically finish. We wrote about this one at length in The Silent Schedule Killer: PTO & Public Holidays, and the mechanics are documented in Capacity Planning with PTO & Holidays: How It Works.

Killer #3: Scope creep — new in 2.13

Which leaves the quietest killer of all. Dependencies and capacity are at least visible if you go looking. Scope creep hides in plain sight: one more “small” ticket, a bug promoted into the release, a stakeholder ask that felt too reasonable to refuse. Each addition is defensible on its own, and the date pays for all of them together. Until now, the app could show scope going up but not much more. Version 2.13 changes that in three ways.

Scope now moves both ways

Previously the burn-up scope line could really only climb. When an issue left a release it simply vanished from the data, so de-scoping was invisible and impossible to audit. Now removals are captured durably — whether you drag a card out of scope in the app or change the Fix Version directly in Jira — and the scope line steps down to reflect them. Pull an item out and the line drops immediately to meet the projection. For the first time, both sides of a scope decision are on the record.

See exactly how fast scope is growing

2.13 stops treating scope creep as a feeling and starts treating it as a rate. The app now expresses scope change as a percentage — for example, 100% growth since you committed — and as a per-day pace such as +10% per day over a ten-day window. That is the difference between “this release feels heavier than it should” and a number you can put in front of a stakeholder who wants to add just one more thing.

The forecast adjusts to scope automatically

Best of all, these scope changes flow into the Monte Carlo simulation, so your P50, P85, and P95 dates react as scope grows or shrinks. A scope-driven slip becomes a dated, attributable event — “the date moved four days when we added these five issues” — instead of a nasty surprise at the deadline. If you want the playbook for pushing back without freezing the backlog, see Managing Release Scope Creep Without Freezing the Backlog and the MoSCoW cut-line reference.

Why this changes product planning and the product lifecycle

Here is the shift. With capacity and dependencies already in the model, scope creep was the last blind spot in the forecast. Now all three of the forces that actually move a release date are measurable inputs to a single probabilistic number. That turns a static roadmap — precise-looking but really just a record of intent — into a living forecast that reacts to reality on every axis at once.

Across the product lifecycle, that closes a loop teams have never quite been able to close in Jira: plan, commit, detect drift, and renegotiate scope against the date with data instead of opinions. A product manager can walk into a trade-off conversation with the exact cost of “one more feature” in days of delay. A delivery lead can flag a slipping release weeks early, with the reason attached. And because the whole thing runs on your team’s real history, the story gets more accurate the longer you use it. For the broader picture of how this fits together, our complete guide to release planning in Jira is the place to start.

Try it on your own releases

Version 2.13.0 is live now on Jira Cloud — no configuration required. Install Advanced Release Planning from the Atlassian Marketplace, read the full v2.13.0 release notes, browse the User Guide, or book a 30-minute demo and we will walk your team through it.

Scope isn’t the only place a release’s story gets scattered across tabs — the Fix Version itself has its own lifecycle from creation to release. See The Complete Lifecycle of a Jira Fix Version for how to manage that whole arc from one screen.

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