Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Nov 17, 2008 — Enterprise Agile Planning expert

Scrum Does Not Say What You Think It Says…

Enterprise Agile Planning

At a recent meeting of a Scrum users group in Portland, Oregon, the topic of release planning came up.

    Management is demanding release dates a year out, but Scrum says not to do that because of the rapidly changing environment that is software development.

My first response is simple, if unsatisfying (and possibly pedantic): Scrum doesn’t say what you think it says. Scrum does not say not to plan releases a year out (and forget what your seventh grade English teacher said about double negatives). If you look up the word “release” in the index of the “black book” (Agile Software Development with Scrum by Schwaber & Beedle, p.158), you will find two entries: “progress” (on page 70) and “Release Backlog” (on page 71). I looked and looked, albeit halfheartedly, having long ago committed most of the book to memory, and I’ll be darned if I couldn’t find anything that said, “Whatever you do, DO NOT plan releases a year out or famine will spread across the land and a pox will be upon you and your house.” Though I have to admit: That would be a pretty cool statement to find in a such a book.

Mike Cohn’s book, Agile Estimating & Planning contains a whole chapter on “Release Planning Essentials.” It says quite a lot about release planning in an agile context and would be an excellent place for beginners to start learning about agile release planning. Surprisingly, it didn’t say not to plan releases a year out, either. (Though, the example given is six months, which implies we should be releasing at least that often).

Now I’m sure you’re saying, “Stop telling me what Scrum doesn’t not say and tell me what it does say,” to which my rejoinder would be, “I think you’re taking the double negative gag too far and please don’t interrupt. I’m getting to that.”

What Scrum and, in fact, most if not all agile methods do advocate is that you apply the appropriate level of detail to the correct planning horizon. In other words, whatever you plan for a release a year out should be at a very high level. You would not want detailed plans of individual stories, tasks and resources, etc. For the simple reason that release plans are predicting the future and the reliability of those predictions decreases the farther out you go, it’s likely the plan will change (thus rendering a detailed plan now wasted overhead that will lead to future rework). One colleague of mine actually considers a “release plan” more a “release strategy” and refers to it as such. I like this nomenclature because it reduces the baggage of plan-driven methods by changing how we refer to our approach to releasing our product.

So we’re all in agreement that Scrum allows us to specify release dates a year out (mostly because I haven’t given anyone an opportunity to rebut my thesis, but let’s ignore that for the present; I know I’m going to). What should we consider when giving management those release dates they are requesting? Another colleague of mine said when discussing this issue, “I believe in fixing the date and tuning the scope. Unshipped inventory is waste, and frequent deliveries build trust.” I think that is good advice, as well. With that in mind, we need to make it clear to management that the reliability of those year-out dates is fairly low, predominantly because we are going to adjust the scope of each release depending on what we learn from each previous development cycle and, more importantly, we are going to empower management to make those decisions based on empirical observation of the current product and the current market. I think that’s a pretty compelling value proposition when selling Scrum to senior management and trying to steer them away from “big up front planning”, which is the only thing about a request for release dates a year out that would give me cause for concern.

Jimi Fosdick

Download the PDF version: Scrum Does Not Say What You Think It Says_blog

More from the Blog

View more
Jul 27, 2021 Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us