Release Planning in Agile projects

"In preparing for battle I have always found that plans are useless, but planning is indispensable" - Dwight D. Eisenhower 
There is always a fear when embracing Agile that things will fall into chaos and that planning and strategy go out the window. I have been on projects that have run into these types of issues and a big part of that stemmed from the team losing sight of the big picture goals and direction for the project. One thing that has been very helpful in preventing chaos and keeping things on track has been: release planning.

What is Release Planning?

Release planning may mean different things in different organizations, but for the purposes of this article I will define it as the process of developing a high-level plan that helps track overall progress within a project and provides a roadmap for upcoming features and key dates that the team will need to be aware of. 

​Release planning is NOT something that is done once to create a plan that is set in stone. It is something that should occur regularly so that plans can be inspected and adjusted regularly to reflect information that has been gained as work is getting completed.

Why is it Important?

• Estimating
• Prioritization / Sprint Goals
• Frequency
• Story Maps
• Visibility
• Key Dates / Milestones

Building a Release Plan

Below I have included the basic process I have used with my teams in the past. This list is by no means exhaustive, and each of these steps can be dived into in much more detail. However, I have kept this at a high level to provide an outline to reference if you are just starting out and want an idea of where to begin. 

• Identify high level goals
• Identify key dates
• Break higher level goals into epics
• Conduct high level estimation on epics
• Select and prioritize epics / stories for next release (use the team's historical velocity if available or something like capacity planning if the team is still learning what their true velocity is)
• Proceed with sprint planning
• Revisit the plan regularly to incorporate feedback from sprint reviews or changes in business priorities

Tips for Release Planning

• Estimating: use something like t-shirt sizing or affinity estimation to ensure that you don't spend a ton of time on estimates that will almost certainly be off or likely to change
• Frequency: if you are using a framework such as Scrum, I would recommend reviewing the release plan during the sprint review or at the beginning of sprint planning to ensure it is happening on a regular basis
• Story Maps: a tool like story mapping can help visually lay out what the projected functionality and stories to be delivered in each release will look like
• Visibility: as mentioned earlier, it helps to make sure the release plan is always available to the immediate team members so they have an idea of where the work they are doing fits into the larger picture and to allow them to better self organize. However, it is also beneficial for the plan to be visible to other stakeholders within the organization so they can see what the general progress on the project is and to help answer the question of: "can I add this new thing in?" or "when will we be done with this?"
• Continuously Re-evaluate: it cannot be emphasized enough that a release plan should not be written in stone. New information will be discovered during the project, surprises and setbacks will happen, and priorities will shift. The release plan should reflect these changes

Final Thoughts

Although release planning is a small piece of the overall planning that occurs throughout an Agile project, making sure your teams are doing this regularly will go a long way towards making sure the project stays on track and building confidence within skeptical organizations that teams using Agile can effectively plan and deliver on higher level goals. 
​
What has your experience with release planning been? Have your teams been resistant to the idea? Is your process any different?