Agile Release Planning: Process & Levels [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on August 03, 2026
10 min read
Agile teams plan more than their reputation suggests — they just plan differently, and at several levels. Agile release planning is the level most people mean when they ask "so when will it actually be done?" It forecasts which features will land by which release without pretending to know everything up front. This guide explains agile release planning in full — the levels of agile planning, its purpose, date-driven versus scope-driven modes, how to forecast with velocity, and how it appears on the PMP and CAPM exams.
What is agile release planning?
Agile release planning is the mid-level planning activity that maps which features or increments a team will deliver across several sprints toward a release or milestone. It bridges the gap between the high-level product roadmap and the detailed, single-sprint work of sprint planning, answering the question of what a release will contain and roughly when it will arrive.
The key word is forecast. Unlike a traditional project plan that fixes everything up front, an agile release plan is a living estimate that's revisited and adjusted every sprint as the team learns more and its real pace becomes clear. It gives stakeholders a realistic picture of what to expect without pretending to a false precision the team can't honor. In practice, it takes a prioritized backlog, the team's demonstrated speed, and a release goal, and turns them into a coarse-grained plan of which features land in which sprint. That plan then guides the team while staying flexible enough to absorb the change agile assumes will happen.
The levels of agile planning
Agile planning happens at several levels, each with a different time horizon and level of detail. A well-known way to picture this is Mike Cohn's "planning onion," where each layer is more detailed and shorter-term than the one outside it. Release planning sits squarely in the middle.
| Level | Horizon | What it plans |
|---|---|---|
| Vision / strategy | Long-term | The product's purpose and business goals |
| Product roadmap | Quarters | High-level themes and epics over time |
| Release plan | Several sprints | Which features ship by which release |
| Sprint plan | One sprint | The stories and tasks for the next sprint |
| Daily plan | One day | The day's work, coordinated at the standup |
The table also answers the common misconception that "agile teams don't plan": they plan constantly, at the right level of detail for each horizon, committing to specifics only as they come near enough to know.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
The purpose of agile release planning
The purpose of agile release planning is to give everyone a shared, realistic picture of what a release will deliver and when, so the team and its stakeholders are aligned without locking into a rigid plan. It translates the roadmap's ambitions into a concrete-but-flexible forecast that people can actually make decisions around.
It serves several goals at once. It creates alignment, giving stakeholders and the team a common understanding of the release's scope and timing. It produces a forecast grounded in the team's real pace rather than optimistic guesses, which sets expectations honestly. It helps coordinate dependencies across the work that a single sprint's view can't see. And it does all this while staying adaptive, since the plan is refreshed as each sprint completes.
Date-driven vs. scope-driven release planning
Every release plan works in one of two modes, depending on what's fixed and what's flexible: you can fix the date or fix the scope, but not both at once.
In date-driven planning, the release date is fixed and the question is how much can we deliver by then? The answer comes from the team's velocity: multiply the velocity by the number of sprints before the date, and that's roughly how many story points of work will fit. The team then prioritizes the highest-value features into that capacity.
In scope-driven planning, the scope is fixed and the question is how long will it take? Here you divide the total estimated story points by the velocity to forecast the number of sprints, and therefore the likely release date.
The essential insight is that you can't fix the date, the scope, and quality all at once. Agile flips the traditional "iron triangle": rather than fixing scope and flexing time and cost, agile fixes time and cost (a stable team over set sprints) and flexes scope. When a stakeholder wants a fixed date and a fixed scope that the team's velocity can't support, release planning is where that impossible request gets surfaced and resolved honestly — by moving the date or trimming the scope, not by pretending.
How to do agile release planning
Release planning is a collaborative session, usually involving the product owner, the team, and key stakeholders. A straightforward process:
- Confirm the release goal. Be clear on the objective the release is meant to achieve, drawn from the product vision and roadmap.
- Prioritize and estimate the backlog. Order the product backlog by value and make sure the relevant items are estimated, typically in story points.
- Know the team's velocity. Use the team's demonstrated velocity — its average story points completed per sprint — as the basis for the forecast.
- Choose date-driven or scope-driven. Decide whether the date or the scope is the fixed constraint, which determines how you calculate the plan.
- Map features to sprints. Working from the top of the backlog, assign items to sprints until you either fill the available sprints (date-driven) or cover the required scope (scope-driven), producing a sprint-by-sprint forecast.
- Share the plan and re-plan often. Communicate the release plan as a forecast with honest uncertainty, and update it at the end of each sprint as real progress comes in.
The plan is only as good as its inputs: real velocity, honest estimates, and a genuinely prioritized backlog.
The release plan and tracking it
The output of the process is the release plan itself: a forecast of which features or backlog items will be delivered in which sprint, building toward the release. It's deliberately coarse-grained — organized around features and epics rather than individual tasks — because its job is to show the shape of the release, not to micromanage the work.
Once the release is underway, progress is tracked against the plan with a release burndown or burnup chart, which shows how much of the release's scope has been completed and how much remains across the sprints. These charts make it obvious early if the team is tracking ahead of or behind the forecast, so the plan can be adjusted — moving the date, trimming scope, or re-prioritizing — while there's still time to act. That feedback loop is what keeps the release plan honest: rather than discovering at the end that the release will be late, the team sees the trend forming and re-plans in response.
Release planning vs. sprint planning
Release planning and sprint planning are both planning activities, but they operate at different levels and it's important not to confuse them. Release planning spans many sprints and works at a coarse level — features and epics building toward a release, over weeks or months. Sprint planning covers a single sprint and works in fine detail — the specific user stories and tasks the team will complete in the next one to four weeks.
The two connect directly: the release plan sets the direction across sprints, and each sprint planning session turns the next slice of that plan into concrete, committed work. Above them both sits the agile roadmap, an even higher-level, longer-horizon view of themes and epics over quarters, from which the release plan draws.
Agile Release Planning on the PMP® and CAPM® Exams
Because the current PMP exam emphasizes agile and hybrid delivery, release planning appears as an example of adaptive, progressively elaborated planning — planning in layers, at the right level of detail for each horizon, and refining as you learn. The facts to hold onto: release planning forecasts a release across multiple sprints, it's based on the team's velocity, and it flexes scope rather than pretending to fix scope, date, and quality simultaneously.
Situational questions often test the date-versus-scope trade-off. Watch for scenarios where a stakeholder demands a fixed scope by a fixed date that the team's velocity won't support — the right response uses velocity to forecast honestly and adjusts the date or the scope, rather than overcommitting the team. Others test the idea that agile plans exist at multiple levels and are continuously refined. Our PMP Complete Study Guide, the most complete on the market, covers adaptive planning and velocity-based forecasting as the exam frames them.
PMP Practice Question: Agile Release Planning
A team is planning a release. The prioritized backlog is estimated at about 200 story points, and the team's velocity has been stable at around 25 points per two-week sprint for the last six sprints. A key stakeholder insists the team commit to delivering the entire 200-point scope by a fixed date four sprints away, and suggests the project manager "find a way to make it work."
What should the project manager do next?
a) Propose adding two contractors for the release window, roughly doubling the team's capacity to cover the full scope by the date.
b) Present the velocity forecast and ask the stakeholder to choose: move the date to around eight sprints, or keep it and rank the backlog so the highest-value hundred points ship first.
c) Commit to the date with the full scope as a stretch goal, while planning internally to deliver whatever actually fits by the deadline.
d) Have the team re-estimate the release backlog before responding, in case the 200-point estimate has room to come down.
Correct answer: B.
Rationale: Six sprints of stable velocity make this forecast about as reliable as agile planning gets: four sprints at 25 points is roughly 100 points of capacity against a 200-point request, and no honest plan can fix the date, the full scope, and quality at once — agile flexes scope. Presenting the forecast and the two real options keeps the decision where it belongs, with the stakeholder, on true numbers. The tempting alternatives all dodge that conversation: a stretch-goal commitment is a broken promise scheduled in advance, and it hides the gap precisely from the person entitled to see it; doubling headcount does not double a stable velocity within four sprints, since new people lower throughput before they raise it; and re-estimating a stably-measured backlog in search of a smaller number is negotiating with the estimate instead of the constraint — a 2× gap does not vanish through rounding. To drill this kind of velocity-based forecasting, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Learners Trust Our Instructors
Frequently asked questions
What is agile release planning?
Agile release planning is the mid-level planning activity that maps which features or increments a team will deliver across several sprints toward a release. It bridges the high-level product roadmap and detailed sprint planning, forecasting what a release will contain and roughly when. It's a living forecast, revisited each sprint as the team learns, rather than a fixed plan set once at the start.
What are the levels of agile planning?
Agile planning happens at several levels, often pictured as a planning onion: the vision or strategy (long-term goals), the product roadmap (themes over quarters), the release plan (features over several sprints), the sprint plan (stories for one sprint), and the daily plan (the day's work at the standup). Each level is more detailed and shorter-term than the one above it, and release planning sits in the middle.
What is the purpose of agile release planning?
Its purpose is to give the team and stakeholders a shared, realistic picture of what a release will deliver and when, without locking into a rigid plan. It creates alignment, forecasts a timeline based on the team's real pace, helps coordinate dependencies, and sets honest expectations — all while staying adaptive, because the plan is revisited each sprint rather than fixed up front.
What is the difference between date-driven and scope-driven release planning?
In date-driven planning, the release date is fixed and you use velocity to work out how much scope fits by then. In scope-driven planning, the scope is fixed and you divide the total story points by velocity to forecast how many sprints it will take. The key point is that you can fix the date or the scope, but not both at once — agile flexes scope rather than fixing everything.
What is the difference between release planning and sprint planning?
Release planning spans many sprints and works at a coarse level, mapping features and epics toward a release over weeks or months. Sprint planning covers a single sprint in fine detail, defining the specific user stories and tasks for the next one to four weeks. The release plan sets direction across sprints, and each sprint planning session turns the next slice of it into committed work.
What is the difference between an agile roadmap and a release plan?
An agile roadmap is a high-level, longer-horizon view of a product's themes and epics over quarters, showing overall direction. A release plan is more detailed and shorter-term, forecasting which specific features will ship in which sprint for an upcoming release. The roadmap sits above the release plan: the release plan takes the roadmap's direction and turns it into a concrete, sprint-by-sprint forecast.
Is agile release planning on the PMP exam?
Yes. The current PMP exam covers agile and hybrid delivery, and release planning appears as an example of adaptive, progressively elaborated planning based on the team's velocity. You are expected to understand that agile plans at multiple levels, forecasts using velocity, and flexes scope rather than fixing date, scope, and quality together — often tested through the date-versus-scope trade-off.
Is agile release planning on the CAPM exam?
Yes. The CAPM covers agile planning, including release planning, usually a little more directly than the PMP — often testing the levels of agile planning, the purpose of a release plan, or the difference between release and sprint planning. Because the CAPM is scenario-based, you should also be ready to apply velocity to forecast a release realistically.
Burnup Chart in Agile: Example & vs. Burndown [2026]
A burnup chart plots work completed and total scope as two lines, so scope stays visible. An example, how to read it, burnup vs. burndown, and the PMP exam.
Minimum Viable Product (MVP): Meaning & Examples [2026]
A minimum viable product (MVP) is the simplest usable version of a product, built to learn from customers. MVP vs. prototype, examples, and PMP exam tips.
Kanban: Boards, WIP Limits & Kanban vs Scrum [2026]
Kanban is a visual, flow-based agile method. The kanban board, WIP limits, its 6 practices, kanban vs. scrum, metrics, when to use it, and PMP exam tips.
