It was around 2004-2006 that I started to connect the dots between some traditional, but low-fidelity, planning techniques I’d been using and agile, or XP at the time, release planning techniques. I think it was the that explored agile planning beyond the individual iteration.

Fast forward to today, and there’s a tremendous amount of discussion (and confusion) as to how release-level planning fits within agile methods and teams. I’m a Certified Scrum Coach (CSC) and as of the Summer of 2013, there’s still a lot of discussion in that community surrounding it. A good part of that is whether it fits into the definition of “Core Scrum” or not. I actually don’t think it does. Another part of the discussion is how it might map to Backlog Grooming, since there is estimation and workflow elaboration in grooming. Again, in my view, it’s not a grooming practice, but having a well-groomed Product Backlog does help your release planning.

I also think context matters when we’re talking about it. For example, if we’re leveraging Scrum or agile methods in a very small, start-up context, then I don’t know if Release Planning is all that useful. The teams are probably learning and pivoting frequently, so sprint-x-sprint planning is probably the right level as they triangulate towards their goals.

But there is a wide variety of contexts where sprint-at-a-time look ahead and planning is too simplistic of a view. Whether we like it or not, many organizations need some sort of release level planning and predictability. It’s just too hard to figure it out as you go. But at the same time, the organization needs to understand that these are flexible plans that will adjust as discovery and progress is made. They simply need a roadmap-level or high-level view to where the team is going and what they’re planning on delivering.

What are the key focus points of Release Planning?

1. It gives the team a sense of the x-team and x-backlog interactions (dependencies) that need to be negotiated to deliver a product. This view is broad—from “release concept” to “released in production” timeframes.
2. It provides a tracking mechanism, establishing a baseline view if you will, so that every iteration or sprint can be compared against planned progress. Often this includes a “release level” burndown chart and an overarching set of release criteria or goals.
3. The thing I like most about leveraging release-level planning is the vision it provides everyone. It’s sort of akin to an architectural diagram at a project level. It’s the big picture and it gets everyone on the same page towards common release goals and functional targets.

In other words: you have directional awareness and a game plan before you—Let Loose the Hounds.

Release Planning – History and Approaches

It turns out that folks have been doing iterative release planning since before the start of the Agile Methods. There’s quite a bit of commonality and overlap in the techniques. I view that as underscoring the value it has for the team. I thought it might be useful to highlight some of the techniques and provide follow-up references for each—sort of a compendium of approaches. I hope you find it useful.

Cards-on-a-Wall

Dwayne Phillips published a in 1998. One of the techniques he spoke to was a “Cards on a Wall” planning technique. It was a low-fidelity technique using 3×5 cards to represent all of the work related to a software project. You would stick the cards to a wall and move them around to represent the workflow. You would identify related work (dependencies) and often could use string to talk about critical paths within the flow.

It leveraged a whole-team view, so everyone (from architect to DevOps; leader to programmer; and developer to tester) participated in the session. It was truly and effort to get the Wisdom of the Crowd into a representative release plan.

I remember using the technique to plan a 100 person software project at Bell & Howell in 1998-99. It worked beautifully and the project came in on-time. The most effective part of the technique was the “shared view” it created for the team for the entire project.

References

TSP Launch Planning

Many years ago, also while at Bell & Howell I introduced the to our teams. A few years after that, the SEI introduced the TSP or . While the PSP was focused on the individual developer, bringing rigor to their individual work, TSP looked at the team dynamics of delivering software.

The Team Software Process has a 4-day launch process defined that is a whole team approach to moving from a requirement list to a detailed, end-to-end plan. The final part of the launch is negotiating (resolving) the plans

References

XP & Scrum Release Planning

I think many of us forget that the Extreme Programming folks had the notion of Release Planning as an adjunct to Iteration Planning. There’s also quite a bit of discussion in the Scrum community surrounding this notion. The two often “look the same” in implementation. Joe Little has written a nice “booklet” that describes his approach for it within Scrum contexts.

I think too many folks get caught up in whether it’s a “Core Scrum” practice and they lose sight that in a wide variety of contexts it can be a critical practice to guide projects as-scale. The envisioning, planning, tracking, and transparency aspects can be crucial for the team and leadership alike.

References

• Joe Little’s e-book:

We’ll continue in the next post with a few additional planning techniques and then wrap things up. My hope is that you find these tools, techniques and thinking models useful in some of your agile contexts.

Stay agile my friends,

Bob.

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