Plan several sprints at once

Question

We are working on a project that will be completed over several months therefore will take several sprints. Our product owner has pushed us into planning several sprints in one go. We have only given rough estimates for items in future sprints (we are only on sprint 1). 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.

I think the main reason for doing this was to give an overall release date to the customer but there are obviously lots of problems. For example what happens with adding bug fixes etc being fed into the backlog?

Answer 1

TL;DR

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:

1. Do a one-pass estimate of all stories, themes, and epics in the Product Backlog.
2. 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.
3. 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.

Answer 2

The short answer: planning future sprints in advance is a bad idea. And I once read that the moon landings were faked; that doesn't make it true though.

Now for the longer answer:

Firstly, one of the primary drivers behind agile development was a recognition that the old way of doing things - estimating everything in advance and setting a release date based on that - just doesn't work in many cases. Estimates are guesses and so will be wrong a times (often, a lot of the time). People tend to under-estimate and it's difficult (impossible, often) to accurately estimate unknows.

By repeatedly iterating over the plan, estimate, work phases, agile methods allow the estimates to be more accurate. This of course introduces a problem for many customers and managers: they aren't given a release date as everything is not estimated in advance. It doesn't matter that such release dates are always missed, they still find comfort in having a date.

One solution to this is time boxing. A release date is set, but no firm commitment is given to what will be released at that time. Another is to involve the customer is the sprint process; so they have a sense of progress, without a promised end date.

Going back to why the Product Owner thinks he read that everything should be planned in advance. The likely thing he's read about is the initial story planning phase. Here, all stories are captured and estimated. They are estimated in arbitrary points though, not in days or hours. This gives the team a sense of the relative sizes of stories and is a useful indication of what stories require the most work, contain the biggest risks etc. This helps the Product Owner prioritise stories (eg, tackle the highest risk stories first).

Sprint planning meetings are then about putting hour estimates against one of more stories (or tasks, if the stories are decomposed). But only for that sprint.