02Where the long horizon went

If planning is so natural, why do so many Scrum teams plan only two weeks ahead? The framework itself is only part of the answer. The larger part is where agile habits were formed.

A framework made minimal, habits made elsewhere

Early Scrum included release planning. The 2011 revision of the Scrum Guide dropped it, describing release planning as no longer a required part of Scrum. The aim was to keep the framework minimal, on the assumption that organisations would complete Scrum with their own practices. Many did not, and anything absent from the Guide tended to disappear from practice.

The practice around Scrum then shifted for a deeper reason. Agile habits were shaped largely by web and consumer software companies. For them, deploying and releasing are the same thing: they ship continuously, measure in production and adjust. Continuous delivery, flow metrics and the #NoEstimates movement all come from that world, and in it a release plan looks unnecessary. Teams under pressure to show progress at frequent intervals drifted towards continuous flow, close to Kanban. For a website or an online shop, that is often the right choice.

Professional software is different

The users of professional software must plan around each release. They train their staff, adapt their procedures, and update their own documentation. In regulated industries they must also validate the new version before they use it. A blood establishment cannot put a new version of its BECS into production 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. Their own plans depend on it. Scrum habits tuned for the short term do not provide one.

Sprint cadence is not release cadence

The confusion behind many planning failures is 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 second cannot be replaced by the first.