I’m going to do something strange in this article. I’m going to ask you to read first. The topic is Agile Chartering, but I think that may not have been the best of titles. Truly the article is about a group of agile teams who found themselves in a bit of a mess in a project and how they leveraged release planning to get themselves realigned with their stakeholders. I published it in the , issue #12, November 2012, so you can get it there as well.

Once you have that story “under your belt”, here I want to explore release planning from two perspectives. The first one will be the ideas of Joe Little and his view towards the focus and steps of release planning. Then I’ll weigh-in with my own version.

As it turns out, they are quite similar, but there are a few important differences. In the end, I’m not trying to tell you Joe’s or mine is better. Instead, I’m presenting two relatively mature approaches to release planning since I find that having real-world examples or approaches is always helpful.

Release Planning – by Joe Little

is a CST in Charlotte, NC. I’ve known Joe for a number of years because he does so much training in our local area. Joe is a solid agile generalist, if you will, but he does have some areas of “special interest”. They surround applying lean principles within agile teams, determining business value, and release planning. It’s the release planning work that I want to expand on here.

Joe recently spent a couple of hours discussing Release Planning with our local group here in the Raleigh, NC area. What was interesting is that he did it without PowerPoint. What was even more interesting was his approach, which I’ll get into next.

The Goal of Release Planning

One of the things I was truly happy to hear is an emphasis on the goal for a release. Joe spoke a lot about first determining a vision and aligning toward some view to a Minimal Marketable Release (MMR) definition. But before that, let’s explore the goal of release planning itself. Here’s what Joe had to say in his follow-up :

To me, the main goals include…

• Increase the motivation of the Team (fingerprints, part of the creation)
• Get everyone on the same page, seeing the same elephant.
• Get alignment.
• Sharing the tacit knowledge
• Team building

Who knew the people were most important?

So the overriding purpose of release planning was team-ward. It involves, using Joe’s terminology, getting the “Elephant” well defined, aligned, and broadening the tacit knowledge around how to “attack it”.

5. The hipbone is connected to the thighbone.

Meaning: Everything we do is, to some degree, connected to everything else. For example, to deal with some issues, one can talk about a solution as part of ‘agile release planning’ or as part of Pareto-izing the work in the course of the Sprints.  To fully understand ‘agile release planning’ one must really understand ‘everything else.’ And yet, we never have time to describe ‘everything else.’

I think the goal-oriented point here is (1) gaining a big picture as a team and (2) developing a shared view on the strategy the team will be leveraging for implementation. I agree with Joe. In fact, I believe that strategy is one of the key outcomes of any release planning effort, but more on that later.

The Steps, Sequence, and Activities in Release Planning

It so happens that Joe has written a small e-book on his release planning approach and recommendations. You can find it on , buy it, and download it in various formats. Basically it contains the following steps for release-level planning:

1. Vision – produce a vision of the product in general and specifically for the release itself – a MMR if you will.
2. Product Backlog – generate a Product Backlog (using PBI’s, User Stories, whatever); at this point it isn’t really organized or ordered in any special way.
3. Business Value – determine business value by playing value poker with your stakeholders.
4. Effort – determine level of effort by playing planning poker with your team.
5. Risks, Dependencies, Learning, MMFs, and other – consider these in your determination of effort AND for potential ordering decision-making.
6. Ordering the Work – in the purest sense, Joe makes the point of factoring Value against Level of Effort in order to determine a Bang for the Buck factor for each PBI. Then using this, you order the backlog. This is your first “iteration” for the Product Backlog.
7. Drawing the Line – based on historical capacity, velocity, gut feel, or whatever you have – draw a line as to what items will fit into the time the business allocates for the release. If the two are aligned perfectly, then fine. If not, you have some ‘splaining to do.
8. “Communications Plan” – and the explanations come via the communications plan. Up to this point, you can expect that the team has come thru one complete “iteration” and has “version 1” of their release plan.
   1. a.     ===== end of Release Plan #1 =====
9. The Fix-It Plan – this is less a step, but rather a model for thinking, as are the next two. Here we realize that the plan is not correct. Potentially it will never be “correct” so we agree to continue to examine, explore, and adjust / fix it.
10. Other things – a big part of fixing the plan is adding other concerns to it. Joe mentioned them earlier as risks, dependencies, learning, etc. Architecture, design, infrastructural needs, and technical flow would be a part of other considerations. As would prototyping needs, external, 3’rd party concerns, and hand-offs. As would testing infrastructure, automation, and functional vs. non-functional testing needs. Regulatory and process concerns would also fall here, and the list goes on.
11. Release Plan Refactoring – Joe mentions in this that he doesn’t like the term Backlog Grooming, instead preferring the term Release Plan Refactoring. So this is the ongoing, grooming equivalent practices of constantly refreshing and adjusting the release plan.

I hope you got a feel for how Joe approaches release planning, but also the overriding goals for it.

One of my concerns surrounds his base goal, that release planning is more for the team. What I mean by that is, if you were an executive interacting with Joe and his teams doing this form of release planning, when would you be able to commit to the contents for a release?  That seems to be a very “wiggly” proposition. Another way of saying it – it seems to be team centric and not plan or commitment centric. But perhaps that’s ok?

Release Planning – by Bob Galen

I’ve been a proponent of release planning for an incredibly long time, probably most influenced by the following points:

• Early on in my XP experiences, around 1999-2001, most of those teams did a form of release planning. You can see it described in by Beck and Fowler.
• Again early on, I was fond of Cockburn’s Crystal methodology and it’s notion/description of . This aligned nicely with my historical experience with similar practices I used with Waterfall approaches.
• And finally, I must admit, that the old message to leadership that “We’ll deliver it…when we deliver it” from agile teams was never very palatable to me. I understand iterative and agile development, but we DO need to communicate SOMETHING externally about our release intentions.

My thoughts and approaches on release planning come out in the article I asked you to read in the beginning. I’ve also written about and around them in my Scrum Product Ownership book. But let’s get into some high-level details so you can contrast this approach against Joe’s.

The Goal of Release Planning

My primary goal for release planning is perhaps best articulated as 3-fold:

1. Establish a view to Vision, Minimal Viable Product (MVP), and Minimal Viable Release (MVR or MMR);
2. Establish an End-to-End view to a Body of Work required for a Release with your team;
3. Align what’s feasible with what’s expected and then establish a baseline plan to get there and commit to deliver.

Now the delivery is never a blood-oath guarantee of scope within a specific time frame. But it IS a baseline view where the team establishes a high to mid level view of the work and then plans the details sufficiently where they feel comfortable committing to the direction, content, and timing.

The Steps, Sequence, and Activities in Release Planning

My activities align broadly with where Joe takes release planning. Let’s take a look:

1. Vision – the first step for me is to establish a MVP (Minimal Viable Product) and MMR (Minimal Marketable Release) definition for the release. I usually like to do this with an “In vs. Out” chart to facilitate feature choices and trade-offs.
2. Brainstorm Backlog – once we have clarity around the “initial Ask” for the release, I like to brainstorm all of the stories for the release backlog. This would include ALL stories and not simply functional ones.
3. Story-Mapping – The next step is to align the stories leveraging approach. I’m looking for the “usage or functional flow”, but also trying to establish a Backbone, Walking Skeleton and Supporting Infrastructure for it. I don’t necessarily like to do value poker, so this is step is actually replacing it, in that the order of the stories implies the value and any trade-offs.
4. Release Swim-lanes Layout – the next step from my perspective is to ask the teams to layout the stories into “Sprint swim-lanes” on a whiteboard, wall or tool of their choice. We still haven’t estimated the stories, but instead are using “gut feel” for the amount of work the team feels reasonably fits into each sprint. This aligns perfectly with the XP Planning Game.
5. Estimate – now comes planning poker. I usually try to get the team to stay at as high a level of estimation as they’re comfortable with. A common level would be T-shirt sizing of S-M-L. Next I ask the team to go through the release plan and estimate all of the stories. Along the way I’m looking for them to add, drop, or change stories based on the discussions.
6. Multiple Pass(es) – I want the team to take multiple passes through the release plan thinking of specific threads or areas of concern. For example: (1) Architecture, design, technical infrastructure; (2) Efficiency of workflow, hands-offs, and dependencies; (3) Any tooling or team-based work supporting needs, and training; (4) Testing, regulatory, process, or documentation; (5) Release concerns, scripts, or deployment documentation; (6) Literally thinking of ALL work required to mature the release from “concept to customer use”.
7. Team Agreed Plan – To exit the planning I’m looking for the entire team to go “thumbs up” that they feel they have identified all of the work to deliver on the goal for the release MMR definition.
8. Negotiation, Re-Plan, Alignment, and Commitment – there’s always some re-planning when the team communicates the “cost” of the release MMR definition. I recommend that negotiation starts with adding/trimming the MMR definition and aligning the scope with the number of sprints (date) the stakeholder can tolerate. The negotiation occurs on the MMR (high level scope items / goals) and Time (in terms of team or multi-team sprints).
9. GO – starting Sprinting
10. Scrum of Scrums – continuously review delivery TO the release plan and make adjustments as each set of sprints executes / delivers.

Probably the biggest difference in Joe and my approach is I want the team to “exit” release planning with a complete view to the high-mid level plan and enough details to be able to “commit” to the plan as it aligns with the MMR. In other words, I want to establish a base-line plan vision that everyone can then start “tracking against” and making transparent “adjustments against”.

I’ve found that getting this level of alignment early truly helps the team communicate and manage expectations.

Wrapping Up

Before I go further, I want to remind everyone that “release planning” is not a practice associated with Core Scrum. I do think it’s a highly valuable practice in quite a few agile contexts, but please don’t think Joe or I are saying every agile team or Scrum team must do release planning.

I think some of my key observations of Joe’s approach are the following:

• Vision centric, Team centric;
• Plan and commitment lite; exploration and understanding heavy;
• Heavy focus on business value; late binding other factors;
• Release planning coupled to backlog and backlog grooming.

And a few on my own approaches include:

• MVP, MVR, and Vision centric;
• Plan and commitment heavy; generate a base-line;
• More intuitive view to business value; parallel consideration of “other factors”;
• Grooming is separate from the release plan; but the release plan does change.

Joe has certainly made me think about my own approach. For example, am I too focused on creating a base line that doesn’t acknowledge the amount of ambiguity that is always lurking in agile – technical projects?

I actually think both approaches work. Truly the most important thing is THAT you release plan; how you do it is much less important. So here we explored two approaches and I hope you’re up to trying one of them or inspired to create one of your own.

Thanks for listening,

Bob

References

• Here’s an early version of Joe’s e-book references in this .
• There are some wonderful references at the end of the article I asked you to read in the beginning, please look them over.
• The notion of MVP, MVR, MMP, MMR, MMF, etc come from the Lean Start-up community.

* – the photo is licensed under Creative Commons Attribution – Share Alike 3.0 license by Luna04 via the French Wikipedia.