Release Planning

---

Origins

Release planning predates Agile by decades — software has always required some kind of multi-sprint coordination. What Agile changed was the relationship between release planning and certainty. Traditional release plans committed to scope, date, and quality up front, then tracked variance from the plan as the project unfolded. Agile release planning starts with two of the three constraints fixed and the third negotiable — usually fixing date and quality while letting scope flex.

Mike Cohn's Agile Estimating and Planning¹ is the canonical reference; the Scrum community's release planning practices, SAFe's PI Planning, and Kanban's forecasting all draw from the same lineage of "plan against ranges, not points."

What a Release Plan Is

An Agile release plan is a forecast of what a team or set of teams will deliver across multiple sprints, expressed with explicit uncertainty. It typically includes:

• The release goal: what outcome or customer-visible change the release is for.
• Scope by priority: must-have items, should-have items, could-have items — usually grouped by MoSCoW or a similar framework.
• Date range or fixed date: when the release happens, with confidence bounds where appropriate.
• Assumptions and dependencies: what the plan depends on that the team doesn't control.
• Risks: what could derail the plan, ranked by probability and impact.

What it isn't: a Gantt chart of tasks. The plan describes outcomes and confidence; the team works out the day-to-day during sprints.

Building the Plan

1. Confirm the release goal

What is this release for? Customer goal, business goal, or both. Without a clear goal, the plan becomes a feature list that's impossible to prioritize honestly.

2. Identify candidate scope

What might be in the release? Pull from the backlog, from stakeholder input, from technical priorities. This is the gross list before filtering.

3. Estimate at the right fidelity

For items the team will start soon, estimate at story-point fidelity. For items further out, T-shirt size or epic-size estimates. Don't pretend more precision than you have.

4. Forecast capacity

Based on team velocity or throughput, how much can the team realistically complete in the available time? Use historical data, not aspiration. Multiple forecasts (optimistic, realistic, pessimistic) make uncertainty explicit.

5. Apply MoSCoW or equivalent

Within the capacity forecast, sort items into Must, Should, Could, Won't (this release). The 60% Must guideline keeps the team honest.

6. Surface dependencies and risks

What other teams, vendors, or external events does the plan rely on? Each is a risk the team should track explicitly.

7. Communicate with explicit confidence

Tell stakeholders the Must list with high confidence, the Should list with moderate confidence, and the Could list as aspirational. Hiding the variation invites disappointment.

Fixed Date, Flex Scope

The default Agile pattern is to fix the date and let scope flex. This makes release planning a continuous decision rather than a one-time commitment. As the team learns through sprints:

• Items prove larger than expected — Could-have items get dropped.
• Items prove smaller — Could-have items get pulled in.
• New high-value items surface — the team negotiates trade-offs explicitly with stakeholders.

This works only if stakeholders accept the scope flexibility. A team that promised "all features" by the date will fail; a team that committed to "must-haves with should-haves likely" can adjust without breaking the contract.

Fixed Scope, Flex Date

The alternative pattern — fix scope and let the date move — works when scope is genuinely non-negotiable (regulatory completeness, contractual deliverables). The team commits to the scope and provides date forecasts with confidence ranges, updated as the team learns.

This pattern is harder. Most "fixed scope" requirements turn out to have some flexibility under examination, and most teams find that fixing both ends produces fictional plans that drift. Use only when scope is truly fixed.

Multi-Team Release Planning

When multiple teams contribute to one release, planning becomes coordination as well as forecasting. Common patterns:

• SAFe PI Planning: a big-room event where teams plan together for the next 8-12 weeks. Heavy ceremony; effective at surfacing dependencies.
• Scrum of Scrums: representatives from each team coordinate at a higher cadence. Lighter weight; less synchronized.
• Dependency mapping events: targeted sessions for surfacing inter-team dependencies, sometimes outside the planning event itself.

The shape depends on how coupled the teams' work actually is. Tightly coupled work needs more synchronization; loosely coupled work needs less.

Updating the Plan

A release plan is a forecast, not a contract. It should update regularly:

• After each sprint — what was completed, what shifted.
• When new information arrives — competitor moves, customer feedback, technical discoveries.
• When risks materialize — the dependency the team was relying on slipped, the architecture problem the team thought was solved isn't.

A release plan that hasn't been updated in three weeks is probably wrong. The discipline is to keep it current and to communicate updates honestly to stakeholders.

Common Pitfalls

• Feature-list release plan: a long list of features without prioritization, capacity check, or risk identification. The plan is fiction; the team will be set up to fail.
• One-time event: heavy upfront planning, then no updates as reality unfolds. The original plan becomes a document people argue against rather than a living forecast.
• Plan with no confidence range: a release plan with single-point estimates and no acknowledgment of uncertainty. Stakeholders read it as commitment; the team treats it as fiction.
• Hidden dependencies: external dependencies the team didn't surface. Discovered late, they derail the release.
• Fixed scope and fixed date: a release plan that fixes both ends usually produces overtime, quality cuts, or both. Pick one.
• Stakeholders not in the loop: a plan the team understands but stakeholders don't. The gap between team's understanding and stakeholder expectation grows until release day produces surprise and frustration.

Coaching Tips

Lead with the Goal

Release plans without a clear goal become feature lists. Start every planning session by writing the goal at the top.

Force the Trade-Off

Stakeholders want scope, date, and quality all fixed. Coach them to pick one to flex — the alternative is a plan the team can't honor.

Surface Dependencies Early

Run a dependency-mapping pass during planning, not after items start. Dependencies discovered mid-sprint cost the most.

Communicate Confidence Ranges

"Definitely the Musts, probably the Shoulds, hopefully the Coulds" is honest. Single-line plans pretend a certainty the team doesn't have.

Update Weekly

A release plan that doesn't move is fiction. Build the update cadence into the team's rhythm — sprint review or release-tracking ritual.

Tell Bad News Early

When the plan slips, communicate immediately. Late surprises destroy trust; early honesty builds it, even when the news is unwelcome.

Summary

Release planning under uncertainty is one of the harder coordination problems in software delivery. The traditional approach — commit to everything up front, then track variance — produces predictable failure for work whose scope, duration, and dependencies aren't all knowable in advance. The Agile approach trades upfront certainty for ongoing honesty: plan against what you can actually predict, communicate the uncertainty, and update as you learn.

The discipline lives in the communication. A team that updates its release plan weekly with honest forecasts produces stakeholder trust over time, even when individual updates contain bad news. A team that holds its original plan and surprises stakeholders at the end produces the opposite. The plan is the basis for a conversation; the quality of the conversation determines whether release planning works.

Back to Agile Delivery