Scrum and Release Planning

This content is syndicated from Agile & Business by Joe Little. To view the original post in full, click here.

I went to the Agile Ottawa group last night. Mostly I very much enjoyed the meeting. But... A Sad Tale A gentleman there, a serious business guy, new to Scrum, said something like this: "It seems to me that Scrum has no up-front planning. And for those of us in the business world who must give some up-front estimate of time and dollars, this is not going to work for us. Does Scrum have some up-front planning?" Several people answered. I gave an answer: YES it does have up-front 'Release Planning.' Scrum does normally include up-front planning. This is somewhat controversial in Agile, but we have it. It is called Release Planning. And I went on to say some of the things I say below. But my comments were brief, and it seemed to me they were drowned out by Agilists saying "why do you want to do up-front planning" (and similar comments)...which is a good question, but again, it likely implied to the gentleman that all we 'scrummers' hate up-front planning. I discussed this with a person in my CSM class the next day. His comment was "yes, based on the stuff I have read [and he had read several things] Scrum does not say much about the up-front planning. I can totally see how that person had that impression." To me this is very unfortunate. Let me now make two references. In the Scrum Guide (located here, among other places), Release Planning and a Release Planning Meeting are specifically mentioned and discussed. In "Agile Project Management with Scrum" by Ken Schwaber there are only two mentions of Release Planning (according to my Kindle) in the book. Both not favorable. So, one can see why some people might get a wrong impression from that book. What's Wrong With Up-Front Planning Now, let me guess why Ken Schwaber minimized the mention of Release Planning in the book mentioned above. First, Schwaber and Sutherland note in the Scrum Guide that a lot of the details about how to do Release Planning are outside the purview of Scrum. Meaning: Scrum is a framework only, and as such, it is probably not useful or necessary for Scrum to give guidance on this that could be seen as Scrum's "answer" for everyone. Starting to do that risks making Scrum too big to implement in one step, relatively quickly. And risks giving great advice (for one effort) inappropriately to another effort or situation. To me, these are quite reasonable concerns, and I think it stretches the point, though, to be so quiet about Release Planning more generally. And, indeed, the Scrum Guide, short as it is, does give a fair amount of guidance on Release Planning. Another hypothesis I have is that Schwaber was concerned that he was seeing too much Release Planning in 'scrum' implementations that looked too much like waterfall release planning. (I think I have seen this some too, although perhaps not as much.) So, what's wrong with that? Well, first, the customer sees no value in Release Planning per se. It is, to use lean terms, at most a 'necessary' waste. So, we want it to be as short as possible (but not shorter). Second, too often people think the main (only) value from the initial release plan is the initial date and budget. Usually, as indicated above, that initial date and budget are necessary information to make some initial basic decisions. Maybe even accurate information if there were to be no changes. But anyone with much experience with projects has a near 100% experience of changes to projects after the Release Planning. Usually quite a number of changes and quite significant. In which case, the initial date and budget quickly becomes moot (in terms of accuracy; possibly still "directionally" useful, if you have a firm that thinks in those terms). Third, often the initial Release Planning date and budget are used to drive people on Death Marches. This is an horrendous and utterly scandalous thing in our industry. It is shameful that we let stupid managers use this information this way, but that's the way it often happens. And unfortunately, this gives Release Planning a bad name too. And partly because of this, many coaches recommend that Release Planning not be done until the Team has established a real velocity. (To me, for reasons I will not explain here, this is the wrong solution to a very real problem.) Fourth, because of the rapidity of change in many areas, many agile people feel that the YAGNI (You Ain't Gonna Need It) principle means that up-front planning should be minimized. Very minimized. Often these people are from business situations where keeping Release Planning quite minimal will actually work. But, in my professional opinion, other business situations actually greatly benefit from some up-front long as everyone uses the plan (and all its refactorings) to drive good behavior (such as minimizing the stories that get in the real "minimum marketable feature set" of the next release). I guess we need to be concrete here, to avoid silly discussions. I won't give all the parameters here (and, to be more accurate, one should), but let me ballpark and say that a typical 3 month release can probably be planned usefully using agile methods (Release Planning) in about 3 days or less. Not a half-day, but again, not 2 weeks or a whole week either. What's Right About Release Planning OK. So we acknowledge that there are 'issues' with up-front planning. (And more than we said above.) These are not issues that either Scrum or waterfall create, but issues nonetheless. Now, let's look at some of the positives. A. Businesses need some way of comparing efforts, to decide which efforts should get started, and which should not start. Exact or even somewhat 'accurate' numbers are not essential here...just some rough sense date/budget and level of accuracy. In virtually all businesses that I work with, this is (or should be, in my professional judgment) a requirement. B. The team needs to start to see, at a middle level, the interrelationship of the benefits and costs of the work (features) it will be building. To make many other decisions (architecture decisions, among them). Again, rough numbers are sufficient usually. And even very rough numbers are better than nothing. Release Planning provides this information. C. A sense of the rough time trade-offs is needed. Customers always want features immediately. When the initial conception of the first release looks, as an example, a long way off, it forces the mind into innovative solutions about how to scope down the first release. Release Planning can give the team enough information to start being innovative this way. D. I think the biggest value of the initial Release Planning is that the whole team starts to see the same elephant. The same effort. In multiple dimensions. The stories (functionality), the business value, the effort (at a story level), the risks and dependencies, etc. This is extremely valuable and, in my experience, the level of 'same-page-ness' is so very much better than what I always did in waterfall planning (and what I still hear). Again, extremely valuable, even though it will change. In part, because it gives the whole team a relatively easy way to 're-plan' the overall effort as things change (really, more "re-see" than just "re-plan"). Let me emphasize that in Scrum, we are always doing "Release Plan Refactoring" every Sprint. (People using Scrum often call this continual replanning other things, but it includes re-planning in multiple ways, such as: adding new stories, using a new known velocity, changing some story points, adjusting some business value points, slicing rising epics into smaller stories, etc, etc. E. The final value is motivation. The team no longer feeling like they are getting the mushroom treatment. They see the 'big picture' at a more meaningful and richer middle-level. The team feels like they are respected. They see themselves as adults making an adult, well-considered commitment to build that product. This motivational impact is quite important. And is not affected by changes much. *** More to say, but enough for now. For those interested, see our earlier posts on Release Planning.

2 Responses to “Scrum and Release Planning”

  1. Nuno Furtado says:

    Your article seems to be cut short. This is actually an interesting topic. I have a hard time seeing how i could use scrumm to plan a project at the tender bid level, where i must estimate all effort based only on a very small and limited specifications document.

  2. Kelly Waters says:

    Hi Nuno, the article is cut short because it is content from an external feed from Agile & Business by Joe Little. Click the ‘read more’ link at the end of the article to see the original post in full on the author’s blog.


Leave a Reply

What is 7 + 6 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”