The release date conversation, finally clear

Every team has had this meeting: a roadmap shows a release date, leadership commits to it, and a few sprints later everyone is back at the whiteboard explaining why it slipped. Roadmap tools draw beautiful timelines, but the dates inside them are typed in by humans.

Release Planning is different. For any Jira release, it gives you three dates and a confidence level on each one — "50% chance by May 10, 85% by May 24, 95% by Jun 7" — calculated by Monte Carlo simulation over your team's real Jira throughput. No guesswork. No optimism bias.

Release 1.2.2 is the version where that probabilistic forecast grows up to handle how real engineering organizations actually deliver.

What's new

1. Multi-team releases, with capacity that actually matters

Real releases are delivered by more than one team. Release Planning 1.2.2 models that natively.

• Multiple teams per product with weighted capacity aggregation, so the forecast reflects the combined throughput envelope of every team contributing to the release.

• Capacity-awareness toggle — run the forecast in throughput-only mode (pure flow data) or capacity-blended mode (throughput weighted by who is actually available).

• Holiday CSV import for public holidays in bulk, instead of free-text guesses.

• PTO picker tied to real Jira users, so the forecast moves automatically when the right people are out.

• User-configurable non-working days on the burnup and forecast charts, so the visuals match your team's actual calendar.

Why it matters. Other probabilistic forecasting tools on the Marketplace compute Monte Carlo over throughput but ignore capacity. Release Planning is the only one that blends both — and now does it across multiple teams on a single release.

2. Release-scoped prioritization and lifecycle

Prioritization frameworks are only useful when they answer the same question as your forecast. In 1.2.2, they do.

• WSJF and RICE scoring scoped to the selected Fix Version, so you're prioritizing the work in this release, not your entire backlog.

• MoSCoW lane view with Must-have / Should-have / Could-have / Won't-have lanes, a draggable cut-line, and a one-click "Move N to " action when scope outgrows the lane.

• Release lifecycle in-app — create a Fix Version, add scope by right-click cascade, reorder releases, see release status in the header, and release the version (with a confirm step) without leaving the planning surface.

• "Hide released issues" as the planning default, so completed work doesn't pollute the in-flight forecast. Toggle it off when you need historical context.

• Working days and priority mapping folded into the product setup wizard, so every new product starts with a calibrated calendar and a meaningful priority scheme.

Why it matters. A roadmap describes intent. Release Planning plans the release you actually committed to — scope, priorities, capacity, forecast, and lifecycle all keyed off one selected Fix Version.

3. Faster, calmer, more Jira-native planning UI

Dozens of small improvements add up to a planning surface that feels like part of Jira rather than a tool bolted on top of it.

• Inline edits on issue cards — Sprint Planning–style summary, estimation, assignee, status, and priority edits directly on the card, with an unsaved-changes indicator and per-card discard.

• Children expand inline under their parent with a chevron toggle, so hierarchy is one click away without a navigation away from the board.

• Smarter relative sizing — Done descendants are excluded from the parent size lozenge, so a near-finished epic no longer dwarfs in-flight work.

• Polished forecast visuals — hover tooltips on the burnup and spaghetti charts, persistent forecast-bar collapse state, scope-line endpoint anchored correctly, and a subtle "Clear filters" button so a refresh never costs a planning session.

Why it matters. Adoption is won by minute-to-minute usability. The 1.2.2 planning surface closes the parity gap with Jira's native Sprint Planning experience, so the learning curve drops and daily use becomes second nature.

4. Enterprise-ready trust posture

The shortest path through security and procurement is a clear paper trail. 1.2.2 ships the artifacts your reviewers will ask for.

• Licensing enabled for standard Atlassian Marketplace entitlement.

• Published Data Security & Privacy Statement describing exactly what Release Planning reads, what it persists, what it never persists, and how it inherits Atlassian's tenant isolation model.

• Documented security disclosure policy so vulnerability researchers have a clear, supported channel.

• Per-scope justifications mapping every Jira permission the app requests to the specific feature that requires it.

• Current user guide maintained in lockstep with the shipped UI, so admins can self-serve onboarding without hand-holding.

Why it matters. For mid-market and enterprise rollouts, the biggest blocker is usually not features — it's the security and procurement review. 1.2.2 ships ready for that conversation.

At a glance

Who this release is for

• Delivery leads, RTEs, and VPs of Engineering who are tired of explaining missed dates.

• Product managers who want to negotiate scope-vs-date trade-offs with data, not opinions.

• Engineering managers and Scrum Masters running scaled Scrum or Kanban on Jira Cloud across more than one team.

• Platform admins evaluating Marketplace apps for enterprise rollout who need a clear security and permissions story before they can pilot.

Try it

Install Release Planning from the Atlassian Marketplace, point it at a Fix Version, and within minutes you'll see your first probabilistic release forecast — backed by your team's actual flow data.

For a guided walk-through, see the in-app user guide. Questions, pilots, or procurement conversations: contact us through the Marketplace listing.

Release Planning — the release planner that tells you the truth.