Release Plan

An RAF C17 carrier aircraft bound for Nepal on 27 April, 2015, loaded with humanitarian aid and supplies. The velocity of the plane, the time it takes each pallet to exit the C17, and the ordering of the pallets define what pallet will land where.

… with the Vision in place you need to craft a plan to gather investment and resources to develop the product. You have a Product Backlog in place and you are using Product Backlog Items (PBIs) that form Product Increments. You have estimated Product Backlog Items in your Product Backlog and you know the velocities of all of your teams.

✥       ✥       ✥ 

The Product Owner needs to be able to communicate to stakeholders when the next release is coming out and which Product Backlog Items the release has. Many organizations require a certain date to be established for the product release whereas other organizations may require the content of the release to be established. When both date and content are required to be certain the Product Owner needs to be able to communicate the risks inherent in this situation.

If the Development Teams can see a committed long-term direction in terms of explicit Product Increments, they are more likely to expend the effort to get there, and are more likely to build the right things along the way that will make it possible to achieve the Vision.

A lack of clear agreement on the content of the next release can give the stakeholders the impression that the scope is negotiable up until the release date. As a result the release date can suffer feature creep and be postponed over and over again.

When the Product Owner has a history with the market, teams and stakeholders with a high degree of trust, an overview plan and estimations alone may be adequate. If on the other hand, the Product Owner is new to the teams, market or stakeholders and there is low trust, or the plan carries a higher-than-normal element of risk, you might need a more detailed plan and estimations.

Product Owners that create a release plan in isolation will miss out on the intelligence and insights of the Development Teams. Furthermore, the teams will not feel ownership of the plan and therefore they will be less likely to feel committed to any forecast.


Create an initial Product Backlog together with the Development Teams that communicates by which sequence of Increments you plan to realize the Vision and maximize value. That is, use the backlog to make a Release Plan. Use that plan to acquire the necessary investor commitment and team forecasts to develop your product.

The focus is always on progress at the product level. If you have multiple Development Teams working together from a single Product Backlog then the knowledge of the teams’ historic velocities may be used to forecast the Product Increments that the teams working together will produce, given the current backlog ordering, but in a way that does not depend on pre-assigning specific Product Backlog in place and you are using PBIs to individual teams. Because velocities have variance, there is also variance in the expected schedule for any set of Product Increments, and a variation in the content of the Product Increments for any given delivery date.

✥       ✥       ✥ 

The Release Plan is an ordered list of deliverables that are to be released in the next few releases. Even with small variance in teams’ velocities, uncertainty can compound to unreasonably large numbers after just a few Sprints. As a rule of thumb, looking beyond three Sprints involves more guessing than statistically justifiable projection.

Together with Fixed Work the Release Plan accounts for all work to bring the PBI to Done. The team may not separate “hardening” work or “quality work” from the rest of the work for any PBI. The Release Plan is regularly updated with the latest insights from the market and the teams’ velocities.

Plan which Product Increments should be released in each release and update the Product Roadmap basing on this plan. Ideally the Product Increments chosen for the next release are assembled from the items at the top of the Product Backlog. Count how many units of estimation, e.g. Estimation Points, the selected Product Increments sum up to and use the known velocities of the teams to estimate the date for each release.

For example, assume that each PBI in the above sketch is estimated as requiring 10 estimation points of work. The team has 6 Sprints of time available to it before 15 July, and we want to know what we will be able to deliver by then. The team has a history of sustaining a velocity between 15 and 20 points per Sprint. All other considerations equal, the team will deliver between 90 and 120 estimation points of work by 15 July. We can count off PBI estimates from the top of the backlog, in this case at 10 points apiece, corresponding to the work we anticipate that the team will complete. In this case they will complete between 9 and 12 PBIs, all other factors being equal.

One could in theory take a more rigorous approach to these calculations: for example, to stipulate that the velocity range between 15 and 20 cover two standard deviations of all velocities for the past 5 Sprints or so. Then, in theory, one would pronounce that the forecast delivery for the next Sprint was 95% certain, and so on with less certainty for subsequent Sprints. However, in reality, parameters like velocity, team constitution, Product Backlog content (it changes!), and market conditions vary enough that the contributions to variance from outside factors undermine any attempt even at statistical certainty. The approach is nonetheless a reasonable indicator and general predictor of the future, much in the same sense that we can more or less depend on the weatherman’s forecast.

Using this approach you can have estimated release dates that can be updated according to team velocities. The approach is found in broad contemporary Scrum practice world-wide. [1], [2], [3]

The Product Owner can either target long-term ROI with a Release Plan that accounts for how PBIs reinforce each other, or can plan a project-styled series of releases based on High Value First. However, the release date should not be used as an exact date for any given PBI, and no delivery date should ever be interpreted as a binding commitment. Scrum keeps delivery dates fixed, so the scheduling of the end of the Sprint is sacred, and it delivers the results of the team’s best effort. The price of agility is some uncertainty. See the pattern Release Range.

It is also acceptable to release some PBIs before the end of the Sprint, releasing the Product Increment a bit at a time to smooth out delivery flow and to minimize the inventory of completed work; see Responsive Deployment.

[1] Mike Cohn. “Planning a Release.” In User Stories Applied. Reading, MA: Addison-Wesley, 2004, Chapter 9.

[2] Mike Cohn. “Release Planning Essentials.” In Agile Estimating and Planning. Reading, MA: Addison-Wesley, 2001, Chapter 13.

[3] Kent Beck. “Planning: Managing Scope.” Extreme Programming Explained, 2nd Edition. Reading, MA: Addison-Wesley, Chapter 12.

Picture from: Sgt Neil Bryden RAF (under CC BY 2.0 license). Solution sketch courtesy of Mike Cohn.