Conclusion
Agile planning is not a lighter version of traditional planning. It is planning done more often, at more horizons, and with uncertainty made visible instead of hidden.
Most of its techniques have been known for twenty years: relative sizing, ordering work by risk and learning as well as value, release forecasts expressed as ranges, explicit buffers for fixed dates. What many teams lack is not the techniques but the horizon. A team that plans only the next sprint cannot build increments that add up to a product, cannot place architecture work ahead of the features that need it, and cannot give its users a timeline they can prepare for.
The BECS example shows what the horizon makes possible. A walking skeleton proves, in the first release, everything that crosses the product's boundaries. Each later release widens every area while staying usable end to end. Four teams work largely in parallel because the product was divided along its business areas and the remaining dependencies point one way. And a blood establishment receives versions it can plan to validate.
Restoring the release horizon, as a forecast rather than a baseline, is the most practical step a team can take towards the essence of Scrum.
Key takeaways
- Planning is natural. It is deciding in advance what we want, what it takes, in what order and what we'll do if things change, then revising as we learn.
- Sprints are not releases. Professional and regulated software needs a release timeline its users trust and have agreed to.
- Forecast, don't baseline. Express plans as ranges, detail them only where knowledge supports it, and update them every sprint.
- Size first, duration later. Estimate by comparison, derive duration from measured velocity, and never use velocity as a target.
- Start with a walking skeleton. Prove the joins between areas first: identity, cross-cutting rules, traceability and the delivery pipeline.
- Grow every area a little at a time. Give each release a goal, and keep every release usable end to end.
- Manage scope deliberately. Every request goes through the backlog and the release goal. Make added and discovered scope visible, and communicate every material change.
- Design away dependencies. Divide the product by business area, keep dependencies one-way, and publish facts when information must flow back.
- Protect fixed dates explicitly. Decide early what gives way, using visible feature or schedule buffers.
- Make sprint planning reliable. Refine before planning, respect the Definition of Done, and commit to a Sprint Goal that makes business sense to users.
- Track progress and scope apart. Use a chart that separates completed work from scope change, and show the forecast as a range that narrows.
A planning health check
- Is there a product goal every team member can state?
- Is there a release goal and a release forecast, expressed as a range and updated every sprint?
- Did the first release of the product, or of its last major part, cross every area end to end?
- Is the backlog ordered by risk and learning as well as by value, with enablers visible?
- Is velocity used only for forecasting, never as a target or for comparing teams?
- Does every Sprint Goal move the release goal forward?
- Would a user recognise each Sprint Goal as useful?
- Are stories refined before sprint planning, rather than during it?
- Is the Definition of Done respected in every estimate and every sprint, with no "hardening" sprints?
- With several teams, is the release planned jointly, with every dependency pointing one way and scheduled at least a sprint ahead?
- For fixed dates, is it clear what gives way, through an explicit feature or schedule buffer?
- Is every material change in scope communicated, with its impact, before stakeholders discover it?
- Does the release chart show progress and scope change separately, counting only work that is done?