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
CST