Agile Release Planning: End-to-End Project Envisioning, part-1

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.


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.


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


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.


  • 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,


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

Bob Galen

Bob Galen

Bob Galen is an Agile Methodologist, Practitioner & Coach based in Cary, NC. In this role he helps guide companies and teams in their pragmatic adoption and organizational shift towards Scrum and other agile methodologies and practices. He is a Principal Agile Evangelist at Velocity Partners. Contact:


  1. Andrés Calviño

    Great post. What a topic!
    My perception is that the effectiveness of these techniques (at least TSP in my experience) is very conditioned to the seniority of the team members. In fact I think that the bigger the seniority gap within the team, the bigger the chance to end up having a “team leader” doing the traditional PM assignments (plan, estimate and team tracking) and so distorting the purpose of the technique. Less senior team members tend to retract and act more passively and let more senior ones (team leader generally is a very senior guy) do the critical stuff.

  2. Bob Galen


    This is a wonderful observation. I agree with you and I want to generalize it beyond TSP. I think the “seniority member” challenge is present in all of the collaborative planning approaches whether agile or not.

    It’s particularly challenging in agile contexts, because of the importance of these techniques being whole team based. I think this is the place where “expert facilitation” can make a huge difference in the quality of the planning. And where a solid Scrum Master (or equivalent coach) is worth their weight in gold.

    Thanks for weighing in! I’d be keen to hear your reactions to the remaining two parts to this series.

Leave a Comment