Release planning and forecasting

Sponsors, boards and customers need to know roughly what will be delivered and when, even on an agile project. Agile teams answer with release plans and forecasts that are updated as they learn, rather than with a single fixed promise made at the start. This lesson shows how the Compass app team planned its releases, how it used velocity and simulation to forecast, and how a forecast that looked fine on averages turned out to need a scope decision.

Levels of agile planning

Agile planning happens at several horizons, sometimes pictured as an onion. At the outer layers sit the organization's strategy and portfolio, then the product vision and roadmap, then release plans, then iteration (sprint) plans and finally daily plans. Outer layers change slowly and are coarse; inner layers change often and are detailed. This is rolling wave planning in agile form: plan the near term in detail, the medium term in outline and the long term as goals.

Roadmaps deserve care. A roadmap with exact dates for every feature for the next year looks reassuring but implies certainty the team does not have. Many organizations prefer outcome-oriented roadmaps (now, next, later) or dated goals with ranges. The Compass roadmap fixed one date firmly, the soft opening, because the lease and the opening campaign depended on it, and left the rest flexible.

Fixed date or fixed scope

A release can be planned in two basic ways. With a fixed date, the question is how much scope will be ready by then; the team forecasts a range of points it can complete and the product owner orders the backlog so the most valuable work falls inside the likely range. With fixed scope, the question is when a defined set of features will be done; the team forecasts a range of dates. Fixing both scope and date, without slack, removes the variable that agile planning relies on and usually leads to overtime, cut quality or a missed date. Release 1 of the Compass app had a fixed date and a scope that could flex.

Forecasting with velocity

The simplest forecast divides the remaining work by average velocity. After six sprints, the Compass team had completed 128 points at velocities of 18, 20, 22, 23, 21 and 24, an average of about 21.3. Release 1 had 190 points, so 62 remained, and three sprints were left before the soft opening. The average suggested 20.7 points per sprint were needed, just under the average velocity, so on paper release 1 was on track. Many teams improve on a single average by using a range: a pessimistic velocity (the average of the three lowest sprints, here 19.7) and an optimistic one (the three highest, here 23). At 19.7 points per sprint, three sprints deliver only 59 points.

Even that range misses something PMP-130 already spotted: the backlog grows. Branch staff and patrons find new needs at every review, and on average about 7 points were added to the whole backlog per sprint, a few of them to release 1. A forecast that ignores growth is too optimistic. Burn-up charts, which show total scope as a separate line, make this visible in a way that burndown charts do not.

Burndown and burn-up charts

A burndown chart plots the work remaining against time, with an ideal line falling to zero at the end of the sprint or release. It is simple and widely used for sprints. Its weakness is that scope changes are hidden: if 10 points are added and 10 completed, the line stays flat, which looks like no progress. A burn-up chart plots completed work rising toward a separate total scope line. Progress and scope change are both visible, so stakeholders can see whether the finish line is moving. For release planning, burn-up charts are usually more informative.

Probabilistic forecasting

A more honest forecast treats velocity and scope growth as uncertain and simulates many possible futures. In a Monte Carlo forecast, the computer repeatedly samples a velocity from the team's history and a scope addition from recent growth for each future sprint, until the remaining work reaches zero, and records how many sprints that took. After thousands of trials, the result is a probability for each possible finish. The Compass team ran this for release 1 with 62 points left, and for an alternative in which the product owner moved 12 points of lower-priority stories to a release 1.1 shortly after opening.

# Monte Carlo release forecast for the Compass app, using past sprint velocities.
import random
random.seed(140)
velocities = [18, 20, 22, 23, 21, 24]
growth = [0, 0, 2, 4, 6]   # points added to release 1 per sprint (sampled from history)
trials = 10000

def forecast(remaining):
    needed = []
    for _ in range(trials):
        left, n = remaining, 0
        while left > 0:
            left += random.choice(growth) - random.choice(velocities)
            n += 1
        needed.append(n)
    return needed

for remaining in (62, 50):
    needed = forecast(remaining)
    within = [sum(1 for n in needed if n <= k) / trials for k in (3, 4)]
    print(f"{remaining} points left: P(done in 3 sprints) {within[0]:.0%}, in 4 sprints {within[1]:.0%}")

62 points left: P(done in 3 sprints) 19%, in 4 sprints 99%
50 points left: P(done in 3 sprints) 92%, in 4 sprints 100%

The averages had said "on track", but once velocity variation and scope growth are included, the chance of finishing all 62 points in the three sprints left is only about one in five. With 50 points left, it rises to about nine in ten. That difference is the information the product owner needs. Amara moved renewals with their business rules (12 points) to release 1.1, scheduled two weeks after the soft opening, after confirming with branch staff that they could renew items at the desk in the meantime. The sponsor was told plainly: release 1 without renewals is very likely by the soft opening; renewals follow two weeks later.

Probabilistic forecasts can also be built from throughput (items finished per week) rather than points, which suits Kanban teams and teams that split work to similar sizes. The principle is the same: use the team's actual history, include variability and scope growth, and express the result as probabilities. Note that the simulation is only as good as its assumptions; if the team changes size or the work changes character, past data predicts less well and the forecast needs revisiting.

Communicating forecasts

Forecasts should be communicated in a form people can use. "85 % likely by 12 March" or "we expect between 55 and 65 points by the soft opening" is more useful than a single date with hidden assumptions. Always say what the forecast assumes (team size, scope growth, no major blockers) and when it will be updated. Stakeholders who are used to fixed predictive dates may find ranges uncomfortable at first; showing them the burn-up every sprint, and how the forecast tightened, builds trust faster than a confident date that later slips.

Releasing more often

Modern software practices make releases cheaper and more frequent. Continuous integration merges and tests changes many times a day; continuous delivery keeps the product always releasable; continuous deployment releases every passing change automatically. Feature flags let a team deploy code with a feature switched off and turn it on for a pilot group or at a chosen moment, separating deployment from release. For the Compass app, feature flags meant the team could deploy release 1 code a week before the soft opening, test it with staff in production and switch it on for patrons at opening.

Releasing often changes the shape of release planning. Instead of large releases planned months ahead, the team ships small changes continuously and uses release planning mainly for coordinated launches, such as the soft opening, where marketing, training and the branch opening all line up. In a hybrid project, those coordinated launches are exactly the integration points with the predictive plan.

Buffers and commitments

When a date really is fixed, teams sometimes plan an explicit buffer instead of, or as well as, flexible scope. A scope buffer reserves a share of the release for should-have and could-have items that can be dropped if needed, which is what MoSCoW's guidance on must haves effectively does. A time buffer, such as a stabilization sprint before a launch, protects a coordinated event such as the soft opening from late surprises. Buffers should be visible and owned, not hidden padding in individual estimates. The Compass release plan showed the 12 points of renewals as the scope buffer for release 1 from the start, which made the eventual decision to move them quick and uncontroversial.