Release planning and product roadmapping are both important practices to achieve product success. But what’s exactly the difference between a release plan and a product roadmap? How do the two tools fit together? This post answers these questions so you can apply the two planning artefacts effectively.
What is a Release Plan?
A release plan forecasts how a major release is developed. It’s a type of project plan—albeit an agile one—and it usually covers the next three to six months. I use the term major release to refer to a version of your digital product that introduces a noticeable change, for instance, by adding or optimising functionality or enhancing the user experience, and it typically results in a new product version—think of Windows 10 or iOS 9.3, for example.
Release plans come in different shapes and sizes depending on the process used. In Scrum, the release burndown chart is the default release plan. It helps you track the progress from sprint to sprint, anticipate if the relevant product backlog items can be delivered on time and budget (or how long it will take and how much it will cost), and make the necessary adjustments, such as, reduce or remove a feature, or add a new team member to the team. The following picture shows a sample release burndown chart.
In the chart above, the vertical axis captures the remaining effort in the product backlog required to create the next release, and the horizontal axis captures the number of sprints necessary or available to develop the release. The first data point on the chart is the estimated effort of the entire product backlog before any development has taken place. To arrive at the next data point, you determine the remaining effort in the product backlog at the end of the first sprint. Then draw a line between the two points. The burndown line shows the progress that has been made, and after a few sprints you should see a trend emerge and be able to forecast future progress. The forecast is represented by the dotted line in the chart above.
What is a Product Roadmap?
A product roadmap communicates how a product is likely to evolve across several major releases. Unlike the release plan, it is a product plan that looks beyond an individual project or release: It describes the journey you want to take your product on over the next 12 months or so—much like a roadmap helps you plan a road trip.
Product roadmaps vary in their format. I prefer to work with goal-oriented roadmaps (also called outcome-based roadmaps). As their name suggests, these roadmaps focus on the goals the upcoming releases should provide. The picture below shows the GO Product Roadmap, a specific goal-oriented roadmap format that I have created. You can download the roadmap template from romanpichler.com/tools or by clicking on the following image.
Let’s take a quick look at the rows of the GO roadmap in the picture above from top to bottom. The first row captures the date or the time frame when a new product release should be available—for example, 1 March 2015, or first quarter 2015. As explained in my post 10 Tips for Creating an Agile Product Roadmap, I recommend using dates or timeframes on internal product roadmaps and omitting them on external ones, that is, on roadmaps that are shown to (prospective) customers. The second row states the name of the release like iOS 9.3 or Windows 10 mentioned before.
The third row is the most important part of the GO roadmap. As its name suggests, it states the goal you want to achieve, the benefit you want to offer. You can think of the goal as a release goal if you work with major releases that package up feature enhancements or releases to make them available at the same time to the users. Sample goals include acquiring users, improving the user experience, and removing technical debt. The fourth row lists the product’s features that are necessary to meet the goal. Derive the features from the goals and ensure that they help create the desired benefits. Focus on what really counts; limit yourself to five features per goal, and keep the features coarse-grained. The fifth and final row captures the metrics to determine if a goal has been met—for example, x amount of users employ the product for at least thirty minutes per day within two weeks after the release becomes available. Stating the metrics ensures that the goals on your roadmap are specific and measurable.
How do the Release Plan and Roadmap Relate?
I find it helpful to think of the product roadmap as a high-level plan that sketches out the major stages of a road trip, including overnight stops. The release plan then states how each stage is likely to unfold. My preference is therefore to derive the release plan from the product roadmap (with the help of the product backlog) and to use the release plan to forecast how a specific product goal on the product roadmap is met. The following picture shows the relationship between the three artefacts.
Don’t forget to keep the product roadmap and the release plan in synch. Bigger changes in the release plan are likely to impact the roadmap. If, for instance, the development progress is slower than anticipated, then this will not only impact the release plan but it might also affect the product roadmap.
The following table summarises the key differences between the release plan and product roadmap.
|Release Plan||Project plan, tactical||3 to 6 months||Product backlog items, including user stories|
|Product Roadmap||Product plan, strategic||12 months||Product/release goals, high-level features / product capabilities|