5 Guidelines for Effective Release Planning

Though most Agile teams tend to do a bit of Release Planning, many times without even realizing it (e.g., Scrum teams often do so during Sprint Reviews), it is an often overlooked practice. This is mainly because teams from different backgrounds or with different levels of expertise either don't really know how to approach it, or simply because they don't see the underlying value of doing so. But every time your team has a discussion about what features will be shipped in an upcoming or in any future product version to be released to users, there's at least a very basic level of Release Planning happening.

If we wanted to roughly conceptualize it, Release Planning is merely the practice of ensuring that the product being built is evolving in the right direction by connecting the product's strategy –determining what desired outcomes we want to drive through one or more releases– with tactics –balancing the work to be done with constraints such as capacity, deadlines and budget while enabling progress monitoring practices. This enables the ability to make informed product decisions, maximize validated learning, orchestrate how to deliver the most value and set appropriate product expectations.

Release Planning is an endeavor that often brings together Agile teams, stakeholders and subject-matter experts, and everyone should collaborate thoroughly. Usually a Product Manager or a Scrum Product Owner ensures the Release Planning's effectiveness and results. In order to facilitate the PM/PO's journey for effective Release Planning and help teams navigate their complexities, we've come up with a few key guidelines to keep in mind:

Release Planning isn't about absolutes, but about informed decisions and predictions.

It's important to demystify the idea of Release Planning as a silver bullet that will guarantee that "everything" will be completed on time. In actuality, Release Planning isn't about ensuring that all work scoped is completed. Rather, it's about making sure that work is appropriately prioritized and that the most valuable things (as discerned by the PM or PO) are at the very top of the backlog, and that it delivers on the desired outcomes for each release.

A typical scenario could be that a team has a fixed delivery date for a major release in a month which includes a bunch of features thoroughly documented in the Backlog. What if the PM or PO says that they want to include ALL those features for the upcoming release? Can the team confidently deliver on that agreement? At this point we don't really know, but in principle it's a high-risk approach to try and fix both a deadline and the scope at the same time. It makes much more sense to either have a fixed deadline and determine how many features can potentially be completed within it, or to only have a fixed scope and determine an approximate delivery date for everything. In any case, there are many intervening factors at play. Agile teams can rely on a set of techniques and tools leveraging empirical data that can help them figure out fairly accurate predictions within their specific constraints and conditions.

Start with the product vision and how it can be represented in a roadmap.

The first big step towards effective Release Planning is to establish clear, specific, and most importantly, measurable goals. A well-exercised Product Vision Board can help you frame your strategic goals, and an Opportunity Solution Tree could get you a few steps ahead by enabling you to frame your work and problems to be solved while defining key measurable results. All these actionable strategic goals can be laid down on a product roadmap to help you drive your efforts.

Even though there are several good tools for creating effective Product Roadmaps, we really like the Goal-Oriented (GO) Product Roadmap designed by Roman Pichler. It has the perfect mix of contributing factors that should be accounted for in a neat, convenient format.

Set up the elements for determining how and when your roadmap goals can be fulfilled.

By now you have a strategic Product Roadmap. You've already discerned what the goals are for one or many more releases, and you have a rough idea of the features that will help you achieve them. But in order to take it one step further, you'll really benefit from prioritizing goals and features in a sensible way. For example, determining which ones are the most critical for your product's success and ensuring that your efforts are focused on delivering the next most valuable thing every time.

A good, practical way of doing this sort of prioritization is to, apart from prioritizing goals, account for the impact of missing on other key delivery constraints like a desired delivery date or within a fixed budget. Let's put it this way: What has the biggest impact on your product?

• Not fully meeting the proposed goal(s)?
• Not releasing on the desired date?
• Going over the allocated budget for the release?

Ideally, you should try to at least keep one of those three constraints open. That way you'll be in a good position to set clear priorities.

The reason for all the latter is pretty simple: even if a team should ideally be able to deliver absolutely all the outlined work within the required timeframe and within budget, this seldom happens. Creating a valuable product isn't a linear process, and unexpected things happen along the way. Market conditions or priorities might shift and affect our assumptions.

Leverage estimation practices that enable you to forecast the cost of delivering on your goals.

With a clear product vision and a set of measurable goals defined and roughly prioritized, the next big thing is to get a ball-park idea of the cost – actual budget or raw resource allocation – associated with each potential release. The best way to get there? Estimating the work forecasted into said releases. Estimation is a key element of effective release planning. It can bring new perspective into where the priorities may be and help you reassess how and when to implement what, or even whether to do something at all.

At the outset, estimations can rely on having the right team of people – subject-matter experts, architects, product specialists, business analysts, and the actual product development team –collaborating to try and draw from past experiences with similar efforts and map out high-level estimates. Estimation practices also enrich the overall learning cycle for product teams as they retrospect on their initial perceptions in regards to the amount of work forecasted to fulfill a feature against the actual effort it took.

Successful teams figure out effective ways of recycling validated learning from the outcomes of previous releases to reshape the horizon of their release plan accordingly and ensure that all factors are converging towards producing sustained user satisfaction.

Continuously validate your release feasibility assumptions against empirical data to guide your progress.

Release Planning isn't a one-time process that you perform once and then forget about. In order for it to be effective, you need to commit to an iterative and incremental approach. Teams enforcing good release practices should be aware that Release Planning unfolds on two different levels:

At the iteration level, most likely during a Sprint Review session. The reason for this is that at this point, there's more certainty and clarity about what features would be completed and potentially releasable. It's important to remember that even though Scrum advocates for producing potentially releasable increments by the end of each sprint, it's the Product Owner's responsibility to decide whether or not to release the increment.

At the Roadmap level, which is more strategic in nature. Here you're usually considering the outcomes of previous releases and the learning they provided, while orchestrating what upcoming releases might look like or whether one or many iterations might be required for it. As previously mentioned, highly collaborative Roadmapping Sessions that involve all the interested parties, as well as subject matter experts, are strongly encouraged.

It's also noteworthy to bring up that Scrum favors smaller batch-size and more frequent releases over big and less frequent releases. The reason for this is that release complexity increases significantly as more features are contained in it, not to mention that the learning process is drastically slowed down because of a longer feedback cycle. An excellent way to track progress is to use Release Burn-down charts. Then you can use that output to continuously feed and refine your Product Roadmap as you move forward.

Hopefully these guidelines can provide you with a framework that helps you lock down the best way to do effective release planning for your teams. Disciplined practice that stays true to the underlying values can positively impact your outcomes. You can make sure you're approaching it in the safest way possible by exerting just enough changes at a time, so your teams assimilate it in their micro-culture as positive and lasting changes.