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.

87

Tagged:

About the Author

Mike Cohn is the founder of Mountain Goat Software, a process and project management consultancy that specializes in helping companies adopt and improve their use of Agile processes and techniques. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a co-founder of the Agile Alliance. He is also a co-founder and current board member of the Scrum Alliance. He can be reached at info@mountaingoatsoftware.com or connect with Mike on Google+.