My manager, Celia, would occasionally stop by my desk and ask, “When are you going to be done?” Behind her casual demeanor she was really asking, “So Kevin, I’ve given you three Scrum Teams to build this application. When am I going to get my money’s worth from them?

A novice product manager might have responded, “We’re Agile. We release when we are ready.” Thankfully, I was not a novice and responded to Celia, “Based on data from the last few Sprints — and what is remaining in the Product Backlog — my release plan points, with high confidence, to releasing in six weeks, with the potential to release early in as little as four weeks.”

My confidence satisfied Celia and was backed by all the work I did with my teams to develop and maintain a solid release plan for my product. While in my early years as a product manager building a release plan was a daunting task. Once I better understood the mechanics and rhythms of release plans, building and maintaining them got a lot easier. For those of you who have a “Celia” in your life (we all do), know that all the hard work spent building and maintaining a release plan is absolutely worth it.

What is a Release Plan?

A release plan is a high-level forecast, typically across multiple Sprints, which describes how you intend to deliver value by releasing your product. A release plan is an invaluable tool because it answers these questions:

  1. Which Product Backlog items will be tackled in which Sprint?
  2. What is in the next release?
  3. When will you be done?

Release plans are mid-level tactics on the Agile planning time horizon that both bring roadmaps to life and add a valuable time dimension to the Product Backlog. A release plan will cover multiple Sprints, and often include multiple Scrum Teams and/or teams across multiple locations. Regardless of the scope, creating a release plan is a collaboration among the product manager, Product Owner, ScrumMaster, Scrum Teams, and stakeholders. Typically, I like to use a two to four-month time horizon for release plans. Release plans that forecast too far in the future include too much variability and inherent schedule risk. The shorter the plans, the faster you release value, and the higher confidence you will have in your release dates. 

Releases can be on a fixed cadence or with a fixed scope — but not both. If the scope of the release is fixed, the plan will produce the expected number of Sprints required to deliver the Product Backlog items scheduled for the release. Alternatively, if the date is fixed, the release plan will indicate what will likely be in the next fixed-date release. The good thing is that the last items to be delivered in the release — and most likely to be cut, if necessary — should be the least most important items.

Begin with the Product Vision & Product Backlog

In order to have a good release plan, you need a strong Product Backlog. Integral to a strong Product Backlog is a shared product vision among the product managers, Product Owners and Scrum Teams. The product vision will help you keep the big picture in focus while building your release plan and to prioritize the things that really matter to your customers and the business.

There are two frameworks that I use to develop and communicate a product vision among the Scrum Teams. Which one you choose is usually based on whether the Scrum Teams are co-located or distributed. For a co-located Scrum Team, Product Box is the best choice. If distributed, I like to use our Shark Tank Vision Template, influenced by McKenna and Moore’s Elevator Pitch framework and shown below. 

 

Pro Tip: In addition to the product vision, consider developing a vision for the next release. A release vision is especially helpful if the release addresses a new market, new persona, or new set of capabilities.

In addition to a product vision, your Product Backlog should include three elements critical to the release plan: 

  1. Items are well-refined (i.e., meeting the Scrum Team’s readiness criteria).
  2. Items are sized appropriately to smaller than a Sprint. Smaller is better.
  3. Items are prioritized based on value.

Pro Tip: There are two highly collaborative frameworks I use with customers and stakeholders to prioritize the Product Backlog based on value: Prune the Product Tree and 20/20 Vision.

The Agile Release Planning Event

Once you have established the product vision, a release vision, and have a ready Product Backlog, you’ll want to schedule a release planning event. Agile release planning events are collaborative events where both Scrum Team members and stakeholders roll up their sleeves and make choices about what to develop as part of the next release.  They usually occur after the roadmap is developed.

A release planning event can span one or more days. Because Agile release planning can be a big investment of time and people, ensure you carve out enough time to properly prepare for this activity. This type of collaborative planning is hard work, so plan to have some fun during the event and remember to celebrate when it’s all over! 

Additionally, regardless of whether you are planning with one Scrum Team or ten, the structure of a good release planning event remains the same:

    1. Share the vision for the next release. The product manager, Product Owner or Chief Product Owner will remind the Scrum Team(s) of the release goals, share the release vision, and explain how this release makes progress toward the overall product vision.
    2. Decide Fixed Date or Fixed Scope Either approach is fine, but it’s important to decide for your business what is most important: releasing on a specific date (needing to hit a market rhythm such as a trade show) or with a set of capabilities (everything included in a customer workflow).
    3. Review the top items in your Product Backlog and establish a cutline. A cutline establishes how deep into the Product Backlog you expect to deliver in this release.
    4. Map out each Sprint. When working with multiple Scrum Teams, each pulls from the single Product Backlog their “local” list of items. Using velocity data for each Scrum Team, plan out which items will likely be delivered in each Sprint.
    5. Capture risks and dependencies. Make time to highlight any significant assumptions, risks, and dependencies that could impact the delivery of the release. Transparency is essential and will be helpful in how you communicate the release window.

Answering the question “When will it be done?”

Now that you’ve done all the hard work, it’s time to answer Celia’s question by estimating the release window. A release window is a range of possible delivery dates based on some type of empirical data.

There are a multitude of reasons why you would want to offer a release window instead of a specific date. Velocities change over time. A release window illustrates that uncertainty and acknowledges that your plan is a forecast, not a precise commitment.  As you deliver value each Sprint, the release window will narrow as unknowns become known, and risks are mitigated or eliminated. 

 In order to calculate a release window follow these steps:

    1. Estimate a high “steady-state” velocity. This will establish the earliest anticipated delivery date.
    2. Re-estimate using a low “steady-state” velocity. This will establish the latest anticipated delivery date.
    3. Calculate the release window. This is the difference between high and low steady-state velocities. 
    4. Add an appropriate buffer. This is a function of the various risks and dependencies within your plan. It can be expressed through time or a confidence factor. I recommend a buffer that is commensurate with the identified risks and dependencies. For instance, if you have many risks and dependencies, have more buffer. If there are fewer risks and dependencies, use less buffer.

Lastly, take a step back and analyze your release plan relative to your roadmap. Recall a good  roadmap will include consideration of market windows, rhythms, or segments you are looking to target. Based on your roadmap, you may need to adjust the Product Backlog accordingly to ensure that your release lines up with the roadmap constraints or targets.

Taking the Next Step

Building that first release plan can be hard work. But once in the rhythm of developing and maintaining your product’s release plan, you will soon find it an invaluable artifact in your product management toolbox. If you would like to learn more about developing a release plan for your product, contact us for help. We are happy to talk to you further and advise you on integrating release plans for your business.

* Written by Kevin Rosengre