Release Planning: Retiring the Term but not the Technique

I want to address a term in the Scrum (and even the broader agile world) that has largely outlived its usefulness: release planning. As commonly used (including by me), "release planning" has meant looking forward a handful (or more) sprints and making a prediction of what would be delivered by then. Ideally these predictions were expressed as ranges, perhaps even using confidence intervals, which is something I've been encouraging teams to do for years. So, we might say, "Six months from now, we're 90% sure we'll be able to deliver between 150 and 200 story points of work."

I still think that is useful and every ScrumMaster should know how to do that.

What's not useful any longer, however, is the term "release planning."

Ten years ago, everyone doing Scrum was doing a model along the lines of sprint, sprint, sprint, release. They'd run one or (usually) more sprints and then release. That isn't true today. Some teams still do that. But others release more often than every few sprints. Some release every sprint. Some even release multiple times per sprint.  I had someone in a class recently who said they average seven releases per day using Scrum.

I've seen this trend coming of course for the past few years. However, I recently realized we've reached a tipping point when the term caused confusion in a class I was teaching. I was describing a "release planning" as projecting forward to the sum of a number of sprints. Someone in the class was thinking that "release planning" meant getting together daily to plan what would be released at the end of the day.

It may be time to retire the phrase "release planning" from the Scrum or agile vocabulary. Don't get me wrong: Being able to predict what will be delivered three, six or twelve months into the future is still essential for many teams and ScrumMasters. But the term is no longer correct. We need a new term.

Over the past year or so I've tried out a few terms in some of my Certified ScrumMaster classes. I don't really want to call it "long-term planning." Maybe in today's world of lean startups, three months can be called "long term" but that doesn't feel right. I'm thinking "Medium Term Planning" could be right. So the techniques remain, but the name has outlived its meaning.


Download Scrum Master Guide

Download Scrum Master Guide

Get a free copy of Situational Scrum Mastering: Leading an Agile Team

Get my free guide now!
Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at hello@mountaingoatsoftware.com. If you want to succeed with agile, you can also have Mike email you a short tip each week.