07Lost horizons

Of all the accountabilities Scrum-in-name-only teams leave behind, planning is probably the most costly. A PMBOK project treats the plan, and its timeline in particular, as the shared picture of where the work is heading. Many Scrum teams have no such picture beyond the end of the current sprint.

Planning confused with the Gantt chart

For many team members, planning means a Gantt chart. The Gantt chart is rejected as "waterfall", and planning is rejected with it. Yet a Gantt chart is only one way to draw a schedule. Planning is the thinking that comes before any drawing: agreeing on the goal, deciding what will not be done, identifying risks and dependencies, sequencing the riskiest work first, matching ambition to capacity, and setting the points at which the plan will be revisited. As Eisenhower put it, plans are worthless, but planning is everything.

Agile teams are meant to plan more than traditional ones, not less. Mike Cohn's planning onion, from Agile Estimating and Planning, shows why.

Scrum covers the two innermost layers explicitly. Earlier versions of the Scrum Guide also described release planning. I believe it was dropped around 2011, to keep the framework minimal, on the assumption that organisations would complete it with their own practices. Many read the minimal framework as the whole method, and anything absent from the Guide was dropped. Long-range planning was the first casualty.

The 2020 Guide partly restored the outer horizon by introducing the Product Goal. A goal gives direction, but it is not a forecast. It does not tell stakeholders when something usable will exist, or which features are at risk if a date is fixed.

Why the horizon shrank

The disappearance of release planning from the Guide explains only part of the drift. The larger part is where agile habits were formed. They were shaped largely by web and consumer software, where deploying and releasing are the same thing: teams ship continuously, measure in production and adjust. In that world a release plan looks unnecessary, and teams under pressure to show progress at frequent intervals drifted towards continuous flow, close to Kanban.

Professional software is different. Its users must plan around each release: they train their staff, adapt their procedures and, in regulated industries, validate the new version before using it. A blood establishment cannot put a new version of its software into service without validating it first, so it cannot absorb a new version every two weeks. These users need a release timeline they can trust and have agreed to, and Scrum habits tuned for the short term do not provide one.

Behind many planning failures lies a confusion between two rhythms. The sprint is the rhythm at which the team inspects and adapts its work. The release is the rhythm at which users receive something they can adopt. A team can work in two-week sprints and release to its customers twice a year. Showing progress every sprint and committing to a release timeline serve different audiences, and the first cannot replace the second.

What a lost horizon costs

• Increments stop adding up. When every sprint is planned in isolation, stories get completed but no meaningful product emerges. The team optimises locally, two weeks at a time, with no reference trajectory.
• Trust erodes. Stakeholders who cannot get a credible answer to "when?" start building their own plans, often a parallel Gantt chart maintained by someone outside the team.
• Work that needs lead time loses out. Architecture, integrations with external parties and regulatory activities need to start before the features that depend on them. Without a horizon, they always start too late.

The remedy is not a return to the PMBOK baseline as a commitment, since that is precisely what failed in high-uncertainty work. Agile practice has its own answer: a release forecast expressed as a range, recalculated every sprint from measured velocity, with explicit buffers where dates are committed. The distinction between a baseline and a forecast is what makes long-range planning compatible with Scrum.

Planning deserves more than a section. The companion article, Agile Planning, covers the toolkit in practice, from relative estimation and risk-based prioritisation to release forecasting and buffering, and shows how it reconnects with PMBOK's own ideas of progressive elaboration and rolling wave planning.