Release Planning & the Early Warning System

Building complex innovative products is, of course, hard.

In that context, what is the purpose of Release Planning in Scrum/Agile?

I will not provide a complete explanation here, but will give a few key ideas.

1. A consensus view of the ‘same’ elephant. I want all the team members to see the whole product and to start to see the same whole product. Typically this is very valuable thing.
2. Think first, but not too much. This is a neat trick — getting some people to think enough before they start, and also helping others not get stuck in ‘analysis paralysis. I find many people want to know ‘perfectly’ certain information before they start. Meaning: They want to wait and study too long. I find this seeking for ‘perfection’ is misguided. It typically does not include enough consideration of what it costs us not to know ‘X’ before we start. (If the cost could be  high, then slowing down to learn ‘X’ makes more sense). I think each team should have a good fight about how much to ‘study’ before starting to Sprint.
3. Establishing a project plan, with a date estimate for the first release and a cost estimate. In most organizations, something like this is usually needed.  (We might take more than one day, though, to improve the estimate and then discuss with the managers.) My experience is that, aside from the discussions about risks and impediments, this is usually the least valuable output. But, the work does establish a starting point for improvement. So, for several reasons, it is necessary.
4. Establishing an Early Warning System. I was just working with a client with a big, multi-team multi-year effort. Some on the team think they will get done ‘early.’ Some think they will be ‘late’ as usual (this is said from my own personal experience that most waterfall projects are late, and this organization is just transitioning from waterfall). In this case particularly, the group (everyone in the group) needs an early warning system that can tell them whether they are likely to hit the date or not. (A date and a high-level scope has been defined, but the detailed requirements are undefined.) For example, the earlier the group knows there is a problem, the earlier it can implement counter-measures to address the problem.

So, the Release Planning sets up the ideas (Velocity, Story Points to be completed, Business Value of the features, etc.) that go into the Release Plan. Thus the Release Plan, with its implied ‘expected Velocity,’ can become the Early Warning System.

In this case, the Chief Product Owner is leading this effort, and it gives him great incentive to get the whole group to do professional Release Planning now. So, for example, refactoring of the Release Plan will take less effort later. The CPO needs to explain and explain again why the whole group wants a ‘pretty good’ Release Plan sooner rather than later. (If they want to do it, will they do it well.) Not an easy job. Do-able, but not easy, especially for beginning Product Owners.