The Product Owner must be educated on how release planning works in an iterative development model. Fixed-scope Sprint Planning is emphatically not how release planning works within the Scrum framework.
In Scrum, release planning is based on estimating the number of time-boxes that are estimated to provide sufficient time to deliver the features being estimated at the time of estimation, with the understanding that estimation accuracy at the beginning of a project have a low confidence interval. An estimate is not a commitment, and the both the content of the time-boxes and the accuracy of the estimates will vary over the life of the project.
NB: The term "release planning" has actually been removed from recent versions of the official Scrum Guide. The SAFe framework still includes it, and attempts to treat it as a complex, multi-day milestone-planning event. There are are certainly other ways to address release planning, but fixed-content Sprints are still not it; generally, you will need to identify value-based milestones rather than a fixed feature set to do effective release planning in Scrum, and your mileage with the technique may vary considerably.
How to Do Release Planning in Scrum
However it still means we have a set list of items in each future sprint. When questioned by the scrummaster the product owner replied that he had read somewhere this was the way to do it.
This is canonically not the way to do this. The correct procedure is to:
- Do a one-pass estimate of all stories, themes, and epics in the Product Backlog.
- Estimate the number of Sprints required to complete the Product Backlog by applying the velocity (or estimated velocity with fudge factor) to the the entirety of the Product Backlog.
- Plan releases based on this initial estimate, while understanding that the cone of uncertainty is large, and that the content of any sprint other than the upcoming Sprint is not guaranteed.
The bottom line is that the Scrum process requires replanning the contents of the upcoming Sprint each iteration at the beginning of Sprint Planning. That is what gives Scrum its agility: the ability to re-prioritize and re-scale the team's available capacity every iteration.
In Scrum, a Sprint is just a container that is filled to currently-available capacity from the list of current priorities. The Product Backlog reflects ongoing changes to priorities, so the contents of future Sprints are not only likely to change, they are actually expected to change as the product and the team's knowledge and processes continuously evolve.
The real problem here is that the Product Owner appears to want to treat Scrum as another type of up-front waterfall planning process. However, in Scrum, nothing beyond the current Sprint is a commitment; it is simply an estimate based on the knowledge available to the team at the time the estimate is made. This paradigm must be clearly communicated to everyone on the Scrum Team, especially the Product Owner.
Release planning with Scrum generally involves setting target dates based on a fixed number of iterations. The Product Owner must dynamically adjust scope each iteration with an eye towards maximizing the value delivered during each Sprint and each planned release. Since Scrum is a time-boxing framework where scope is expected to be the flexible parameter, release dates are generally the (relatively) fixed quantity, while the scope of each release (e.g. what features are actually included in each planned release) is usually the variable quantity.
This is mitigated by the fact that each iteration should result in a product that is in a potentially-shippable state. That doesn't mean it is guaranteed to be feature-complete; in the software world, it simply means the code compiles, and any features that are currently included meet the current Definition of Done. All else is malleable, and meant to be iteratively improved Sprint after Sprint until it is "good enough" for the project to be declared a success and formally closed out.