…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 contains. Sometimes, the release date is an important constraint, and other times the release contents are the main constraint. The risks inherent in an over-constrained problem arise when constraining both the date and contents, and the Product Owner must make such risk transparent.

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 toward the product 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 from feature creep and the team ends up postponing delivery 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.

Therefore:

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 they can use their historic velocities (see Notes on Velocity) 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 Items to individual teams. Because velocities vary, 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 for the next few releases. Even with small variance in teams’ velocities, the delivery schedule becomes unreasonably uncertain 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 (see Definition of Done). The team may not separate “hardening” work or “quality work” from the rest of the work for any PBI. The Product Owner regularly updates the Release Plan with the latest insights from the market and the teams’ velocities.

Starting at the top and working your way down the backlog, sum each PBI’s estimation units (e.g., Estimation Points) until you reach the sum of the known team velocities. The Product Increment for the next release comprises these items at the top of the Product Backlog. Continue your way down the backlog to collect PBIs into Product Increments and to assign Product Increments to successive releases. Update the Product Roadmap based on this plan.

For example, assume that the team estimates each PBI in the above sketch requires 10 estimation points of work. The team has six Sprints of time available to it before July 15, 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 July 15. 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 covers two standard deviations of all velocities for the past five 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.

A common agile phrase is the recommendation to “defer decisions to the last responsible moment.” Some PBIs may have a target date that constitutes such a “responsible moment” (a desired or mandated delivery date), but responsible lean practice pulls decisions forward instead of deferring them. Release planning uses the Product Backlog as a framework for pulling decisions as far forward as possible (e.g., considerations of dependencies between PBIs, or the alignment of PBIs or product increments to a release date). All else being equal, it is important to initiate work as soon as possible, since design and implementation help make emergent requirements visible early, and give the team early data about risk. Deferring work, or the decisions that drive work, only delays the inevitable. See “Positive versus Negative Iteration in Design” in [1], and also Dependencies First and Refined Product Backlog.

Using this approach you can update estimated release dates according to team velocities. The approach enjoys broad contemporary Scrum practice worldwide. See “Planning a Release” (Chapter 9) in [2]; “Release Planning Essentials” (Chapter 13) in [3]; and, “Planning: Managing Scope” (Chapter 12) in [4].

The Product Owner can either target long-term value (see Value and ROI and ROI-Ordered Backlog) 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 team should not use such estimates as exact dates for any given PBI, and no delivery date should ever be interpreted as a binding commitment. The Release Plan is based on estimates and acknowledges flexibility rather than inevitability. Scrum keeps delivery dates fixed, so the Sprint end date is sacred, at which time the team delivers its 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] Glenn Ballard. “Positive Versus Negative Iteration in Design.” In Proceedings of the 8th Annual Conference on the International Group for Lean Construction (IGLC-8), Brighton, UK, 2000.

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

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

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

Picture credits: Sgt Neil Bryden RAF https://www.flickr.com/photos/14214150@N02/1666970766 (under CC BY 2.0 license). Solution sketch courtesy of Mike Cohn.