Is it OK to plan several Sprints in advance?

In this episode, Professional Scrum Trainer Sam Falco answers the question: "Is it OK to plan several Sprints in advance?"

I’ve seen this practice in many organizations. Product Owners plan four, five, even six Sprints of work for their teams. The result is something like a Gantt chart with Sprints instead of weeks as the unit of measure. It’s a bad practice with many drawbacks and no real benefit.

It diminishes transparency

The Scrum Guide’s description of the Product Backlog gives us our first clues that planning Sprints in advance is a bad practice.

• “The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.”

Assigning Product Backlog items to future Sprints means that you’re splitting your Product Backlog into multiple lists. The order is more difficult to see, and instead of a single source of requirements, you now have several.

The Scrum Guide also says that the Product Backlog is dynamic and constantly changing. Having Product Backlog Items scattered over a number of Sprints makes managing this dynamic change more difficult than if you have a single artifact. In one organization I was in, Product Owners would plan an entire Program Increment and then spent a significant amount of time trying to manage multiple forecasted Sprint Backlogs as well as the remaining Product Backlog.

It diminishes self-organization

When multiple Sprints are planned in advance, the Development Team loses its role in collaborating with the Product Owner to craft a Sprint Goal and select Product Backlog Items into the Sprint Backlog that they believe will help achieve that Sprint Goal. Often, no Sprint Goal is identified—instead, the goal is for the Development Team to “do all the things.” The Development Team’s autonomy is hobbled, and it is robbed of the opportunity to self-organize around a coherent, meaningful goal.

It diminishes inspection and adaptation

The Scrum Guide closes its definition of the Product Backlog by pointing out that while forecasting progress may prove useful, forecasting techniques “do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.”

Planning multiple Sprints in advance means that we are making decisions about the future based on what we expect will happen. Sprint six is planned based on what we expect to do in sprints one through five, for example. We’re making assumptions about the future before we have a chance to validate what we’re doing right now. It tends to result in attempting to produce to a forecast rather than basing our work on current business conditions.

But how do I forecast?

Proponents of planning multiple Sprints in advance say that they need to do it in order to forecast release dates. But as Scrum Master Yoda said, “Always in motion is the future.” Planning several Sprints at a time, only to have to re-plan them as things change is wasteful and doesn’t create certainty.

Instead, we should embrace uncertainty and incorporate it into our forecasts, providing a target range that widens the farther out we look.

Forecasting with Scrum is best done by understanding our team’s velocity (as it actually is, not as we want it to be). We can use what we know about the team’s historical ability to deliver to make a “good enough” estimate of the least and most they are likely to produce.  

Want to Learn More or Get in Touch?

Register for our upcoming web meetings by visiting agilethought.com/events

See available training courses at agilethought.com/training.

Visit the website and catch up with all the episodes at AgileThought.com!

Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!