Release Planning

What it is

Release Planning sits between the product roadmap and sprint planning. While the roadmap expresses strategic intent (“we want a mobile app by Q3”), release planning translates that intent into a grounded, time-bound forecast using the team's actual velocity and the backlog's estimated size.

The process uses the team's velocity range and the sum of backlog estimates to model when a set of features will be ready. It does not promise exact dates; it provides a probabilistic forecast that improves as the team accumulates more velocity data and the backlog is refined.

There are three common planning scenarios, and each requires a different conversation with stakeholders:

• Fixed-date: The release date is immovable (regulatory deadline, marketing launch). The team forecasts how much scope can be completed by that date. Scope is the variable.
• Fixed-scope: The feature set is non-negotiable. The team forecasts when that scope will be done based on velocity. Date is the variable.
• Fixed-everything: Both date and scope are locked. This is the riskiest scenario and usually signals that planning assumptions will break. The team's job is to make the uncertainty visible early.

Good release planning acknowledges uncertainty with ranges. Instead of “we'll ship on 15 August,” the plan says “we are 85% confident of shipping between 1 August and 22 August.” This honesty protects the team and sets realistic stakeholder expectations.

When to use it

Release Planning should be revisited monthly or per Programme Increment (PI) in SAFe environments, and whenever priorities change significantly. Specific triggers include:

• At the start of a new quarter or programme increment.
• When major scope is added or removed from the product backlog.
• When team velocity shifts significantly (new members, structural changes, or sustained trend changes).
• When stakeholder funding or commitment decisions require a delivery forecast.
• After a major release, to replan the next phase based on lessons learned.

Key concepts

Fixed Date

In a fixed-date scenario, the team divides the number of sprints remaining until the deadline by the velocity range to determine how many points of scope can be delivered. The Product Owner then prioritises backlog items to fit within that capacity. Lower-priority items are deferred to a subsequent release. This is the most common and agile-friendly scenario because it preserves scope flexibility.

Fixed Scope

In a fixed-scope scenario, the team sums the points for the required features and divides by the velocity range to estimate how many sprints are needed. The result is expressed as a date range, not a single date. Stakeholders must accept that the date is a forecast, not a promise, and that new information may shift it.

Probabilistic Forecasting

Instead of a single date, probabilistic forecasting uses Monte Carlo simulation or simple historical analysis to say things like: “There is a 50% chance we finish by 10 August, an 85% chance by 24 August, and a 95% chance by 7 September.” This gives stakeholders meaningful trade-off information: is the 85% date good enough, or do we need the 95% date and should cut scope to get there?

Roadmap vs Release Plan

The roadmap is strategic and high-level. It communicates intent to executives, customers, and investors. The release plan is tactical and grounded in team data. It communicates feasibility to the team and delivery confidence to stakeholders. The roadmap may say “API v2 in Q3”; the release plan says “API v2, sprints 14–18, 23–31 August, pending no scope changes.”

Programme Increment

In SAFe and large-scale agile, a Programme Increment (PI) is a timebox of 8–12 weeks during which an Agile Release Train delivers incremental value. Release planning at the PI level involves all teams, identifies cross-team dependencies, and commits to a set of objectives. PI Planning is the most structured form of release planning and requires significant preparation.

Common pitfalls

• Treating the release plan as a contract: Once stakeholders see a date, they treat it as a commitment. The plan must be framed as a forecast from the start, with explicit agreement that it will be updated as new data arrives.
• Not updating when velocity changes: If the team's velocity drops from 35 to 25 after losing two members, the release plan must be revised immediately. Leaving the old plan in place creates a widening gap between expectation and reality.
• Ignoring uncertainty: Single-date forecasts are comforting but false. Ranges, confidence levels, and scenario planning are harder to communicate but far more honest and useful.
• Planning too far ahead: Release plans beyond three months are largely speculation in most software environments. The backlog will change, priorities will shift, and the team's composition may evolve. Plan the next release in detail; sketch the one after roughly.
• Disconnecting from sprint feedback: If the release plan is created by a project manager and never reviewed by the team during sprint events, it becomes fiction. The team must own and update the plan based on what they learn each sprint.

NZ context

In New Zealand, release planning often needs to align with external rhythms that are not negotiable: funding cycles (especially in government and DHBs), marketing campaigns tied to seasonal events or agricultural cycles, and regulatory deadlines such as tax year changes, financial reporting dates, or compliance milestones.

Government digital teams in NZ frequently work to financial year boundaries (ending 30 June) and quarterly reporting to Ministers or boards. Release plans in these environments must speak the language of these cycles while preserving the agility to replan when velocity or scope shifts. A fixed-date release plan is often the pragmatic choice because the date is genuinely immovable.

NZ's small market size means a single failed release can have outsized reputational impact. Release planning therefore carries higher stakes than in larger markets. The pressure to hit dates is real, making it even more important to use velocity ranges, communicate uncertainty early, and manage stakeholder expectations transparently.

For teams working with offshore partners or distributed across NZ cities, release planning must account for time zone delays, handoff overhead, and the slower feedback loops of remote collaboration. These factors often reduce effective velocity and should be baked into the release forecast from the outset.

Career level guidance

Senior

• Own the release planning model. Maintain the spreadsheet, Jira roadmap, or board that connects backlog items to projected sprints and dates.
• Present release forecasts to stakeholders using ranges and confidence levels. Resist pressure to collapse a range into a single date unless the scenario is genuinely fixed-date.
• Update the release plan within 48 hours of any significant velocity change, scope shift, or team change. Stale plans erode trust faster than revised plans.
• Identify and communicate dependencies between teams, systems, or vendors that could derail the release plan. Surface these early, not at the deadline.

Test Lead

• Ensure release planning includes test phases, environment provisioning, and regression cycles. A release plan that ends at "development complete" is incomplete and dangerous.
• Advocate for quality gates in the release timeline. If user acceptance testing, security review, or performance testing are required, they must appear as explicit items with time allocated.
• Use the release plan to forecast when quality debt will be addressed. If the plan pushes all refactoring and bug fixes past the release date, raise the risk with stakeholders.
• Prepare contingency scenarios. What happens if critical defects are found in the final sprint before release? A good release plan includes a buffer or a rollback strategy.