A release planning meeting turns a roadmap goal into a plan the team can deliver: which scope goes into the release, across how many sprints, and on what date, with how much confidence. It is the meeting product teams are running now as they plan Q4 and next year. This guide covers who should attend, what to bring, a six-step agenda, and the outputs that should exist when you leave the room.

It is part of our release planning guide. If you are unsure how this meeting differs from sprint planning, start with release planning vs sprint planning.

Purpose

A roadmap says what the product is aiming for and roughly when. A release plan says what will actually ship in the next release, typically covering the next few months. The release planning meeting is where the two meet: the product owner brings intent, the team brings capacity and estimates, and the group agrees scope, sequence and a date range everyone can defend. (More on the distinction in roadmap vs release plan.)

Who attends

• Product owner — owns scope and priority.
• Developers from every team contributing to the release — own estimates and technical risk.
• Scrum Master or delivery lead — facilitates and owns the capacity numbers.
• Representatives of dependent teams — only for the dependency section.
• Key stakeholders — for the opening (goal) and closing (commitment) only.

Inputs to bring

• A release goal in one sentence.
• A prioritised list of epics and stories for the release, estimated at least roughly.
• Historical velocity or throughput for each team, from the last several sprints.
• Known capacity changes: leave, holidays, people joining or leaving.
• Known dependencies on other teams or vendors.
• Any fixed dates: contractual, regulatory, marketing launches.

Release planning meeting agenda

1. Release goal (10 min). Product owner states the goal and why it matters now. Stakeholders confirm it.
2. Scope walk-through (30–45 min). Walk the prioritised list. Clarify, split, and re-estimate items the team cannot size.
3. Capacity (15 min). Sprints until the target date, multiplied by realistic per-sprint capacity after leave and holidays. Use a range, not one number.
4. Fit and cut line (20 min). Lay scope against capacity. Draw a line: above it is committed, below it is at risk. Agree what gets dropped first if the date is threatened.
5. Dependencies and risks (20 min). For each item that depends on another team, name the owner and the date it is needed.
6. Commitment and confidence (10 min). Agree the date range and a confidence level. A quick team vote works; record the result.

Outputs

You should leave with five things written down: the release goal, the committed scope and cut line, the target date range with a stated confidence, the dependency list with owners, and the assumptions behind the capacity number. The last one is usually skipped, and it is the one you will need when the date starts to move.

Common failure: the plan is never re-checked

Most release plans are accurate on the day they are made. Then scope is added, a dependency slips, two people are pulled to support, and nobody reruns the numbers until the final sprint. Treat the release plan as a forecast that updates every sprint, not a document signed once. Our guides on release date forecasting and managing release scope creep cover how to keep it current.

The date agreed in this meeting is a snapshot. Scope creep, a dependency surfaced too late, or a capacity change can each move it within weeks, which is why it pays to keep the committed date live after the meeting ends. For the Jira setup behind the plan itself (Fix Versions, dates, and forecasting), see release planning in Jira, step by step.

Running it in Jira

In Jira, the release is a Fix Version, but the version itself does not forecast a date from team capacity. Advanced Release Planning, Roadmaps & Management for Jira by Divim is built for this meeting: it plans release scope across teams and sprints, forecasts the delivery date from real velocity and capacity, shows cross-team dependencies, and flags when scope changes push the date. Bring it up on screen during steps 3 to 6 and the fit, cut line and confidence discussion happens against live data instead of a spreadsheet.

For dependency-heavy releases, Divim’s Dependency Manager maps the cross-team links discussed in step 5.

Summary

• Bring a goal, estimated scope, real velocity, capacity changes and dependencies.
• Follow six steps: goal, scope, capacity, fit and cut line, dependencies, commitment.
• Leave with a date range and confidence, not a single date.
• Re-forecast every sprint.

Back to the release planning guide.