Release planning is an estimated management target, generally based on level-of-effort estimates of large themes or epics. Sprint Planning is a team commitment based on iteration-sized user stories. They serve different functions, but the key is to remember that estimates are not guarantees.
Schedule changes do not necessarily imply that your estimates are inherently wrong. Your goal should be to improve the accuracy of your estimates, not to meet arbitrary scheduling targets. However, improving the accuracy of your estimates should reduce variations in your estimate-based scheduling to acceptable levels.
Release Planning in Iterative Development
Release planning is primarily about defining milestones and expected shipping dates. The cone of uncertainty is always largest at the start of a new project, and therefore the accuracy of the initial release plan should be a range with a defined confidence interval.
Because Scrum is an iterative development process, release planning should be revisited every iteration. Based on what is currently known at the start of each iteration, the Product Backlog can be modified to reduce scope or change priorities to hit fixed release dates, or the release dates can be moved to more-accurately reflect the team's actual progress towards the planned release.
There are a number of core ideas behind agile development, but one of the core concepts is the idea of iterations that produce "potentially releasable increments." In other words, while any given sprint might not contain the complete set of features planned for a given release target, each sprint should produce a working, functional, and (ideally) user-visible feature that could be released.
Put another way, every sprint should result in a product that has generated some amount of earned value. While the product might not be feature-complete, it is nevertheless functional and potentially shippable at the end of each sprint. This gives stakeholders the ability to convert earned value to market value at the end of every iteration, although they are certainly not required to do so.
The key to successful Scrum implementations is to continuously re-estimate. This re-estimation obviously includes epics, themes, and user stories, but it also includes re-estimating project timelines and the scope of target milestones.
Deviations from initial estimates are to be expected, and are handled by the inspect-and-adapt process baked into Scrum. However, if you find that your estimates are not growing more accurate over time, then you need to:
- re-evaluate your estimation process to see where you might improve, and
- determine whether your original scheduling-baseline was based on faulty assumptions.
Management Needs to Embrace Change, Too
"Embracing change" is not the sole province of the development team in Scrum. It is also the responsibility of the Product Owner and stakeholders to embrace all necessary changes to scope, schedule, resources, market forces, and other realities that are needed to ensure the project either succeeds or fails early.
Sticking to a plan made months or years ago, without taking stock of where the project is now, is one of the most common ways that projects fail. Agility doesn't guarantee success; it just expects the visibility and transparency of the project to enable stakeholders to make well-informed decisions.