Paraphrasing a well-known concept in project management, one might say, “Planning is indispensable, but plans are useless. Hence, inspect and adapt.”

Traditional plans are driven by dates – most likely with an end date being the primary driving factor. In traditional project management, you gather the requirements from your stakeholders, build the scope of the project, and break the project down to manageable pieces of work. This, in turn, creates a work breakdown structure (WBS). Next, the lowest level of WBS, i.e., work packages, are further decomposed into activities. The activities are then linked with dependencies, and resources are estimated and applied to activities to create an end-to-end schedule for the project. This schedule is then monitored and controlled with the help of a schedule management plan, which is usually a subsidiary plan of the consolidated project management plan.

But, how many times did it happen that what you planned and what actually happened on the ground, matched? You already know the answer! The opening quote signifies that planning is essential, but expecting that we can follow the plan exactly is not a wise thing to do. When there are high churns in requirements and high uncertainty in technology or platform, PMs usually go with adaptive (or Agile) life cycles.

In fact, the fourth value in the Agile Manifesto says: “Responding to change over following a plan.” Agile is change driven, and most likely, these changes will be driven by customers. This leads to a concept called Agile Release Planning.

Release planning is unlike traditional planning, where the complete plan is considered upfront, elaborated on in detail, and can only be changed with formal change requests. A release plan can be updated many times based on the feedback from previous iterations.

Because adaptive life cycles are incremental in nature, organizations can release at the end of every iteration. They can also choose to release after a few iterations or even continuously. This necessitates a longer-term planning, but can be effectively facilitated by utilizing the release planning technique, which was newly introduced in the 6^th edition of the PMBOK Guide.

For aspiring Project Management Professionals (PMPs) and Certified Associates in Project Management (CAPM) , Agile Release Planning is a key concept to know. The PMBOK Guide 6^th edition has introduced Agile considerations for every knowledge area. This is also useful for aspiring Agile Certified Practitioners (ACPs).

As we get into this more, let’s first see how the release plans are developed at a high level.

 

From Vision to Roadmap to Release Plans

In Agile projects, work starts with a product vision. The vision then translates to a product roadmap. The roadmap contains the features to be developed over a period of time. You can also say a roadmap represents the scope of the product, which is delivered in various releases. This leads to the release plans and is shown in the figure below.

 

Roadmap and Product Backlog

One component in the above sequence is product roadmap, and to understand product roadmap, first we need to understand product backlog. In Agile approaches, all the requirements – both project requirements and product requirements – are part of the product backlog (PB). Each item in the product backlog is called a product backlog item (or PBI). Other than features (requirements), a product backlog item can be a change request, defect, bug, issue, or even specific technical work.

As we know, in Agile projects, the requirements are continuously evolving and there are significant uncertainties/risks. As a result, we usually prioritize the PBIs. The prioritized PBIs are taken from the top of the backlog and delivered to the customer(s). High priority items remain on top of the backlog and are fine-grained, whereas low priority items are at the bottom of the backlog and coarse-grained. The prioritization of the items in the PB determines the level of detail for that item in the product backlog. This is depicted in the below figure.

If you are using Agile tools such as Microsoft Project, you can develop the product backlog quickly. An example product backlog, drawn with MS Project, is shown below.

Here, we have a product backlog showing the product backlog items (PBIs) of “Create a new user,” “Log into the online trading system,” “Transfer a stock,” etc. If you wanted to add any other backlog item, you’d just have to click on the “+” icon of “New Task” command box.

The top-level items in the product backlog can be written in user stories, which are estimated in story points – a relative unit-less measure.

Now, coming to the product roadmap, you can simply say it is a product backlog with a timeline. A roadmap depicts the planned future of the project (i.e. planned and/or proposed product releases) or release themes, listing high-level functionalities of the product. The roadmap tells what features or epics (an epic, simply speaking, is a big user story) will be delivered in each release.

 

Release Plan

The product roadmap drives the release plans. A release plan gives the release schedule – each release typically being three to six months. A release contains many iterations – from Iteration 0 (iteration zero) to Iteration N. Iteration 0 can be used for project approvals, setting up the environment for the project, initial overview and design discussions, etc. Some Agile practitioners use Iteration – H (hardening iteration), which is the final iteration at the end of the release to prepare for delivery. This iteration can include final work items such as training and marketing materials, final release notes, installation guides, system/user guides, etc. This is depicted below.

As shown, the release plan has iterations – from “Iteration – 0” to “Iteration – N.” You can decide to have a release after a few iterations and/or a final release after the last iteration.

The release plan presents a roadmap of how the team intends to achieve the project vision within the scope of project objectives and constraints. It helps the product owner and whole team decide how much must be developed and how long it will take before they have a releasable product. It conveys expectations about what is likely to be developed and in what timeframe. The release plan can also serve as a guidepost towards which the team can progress. The release plan can be updated at the end of an iteration, and it reflects the current expectations that will be included, so that they can be delivered in subsequent iterations.

 

Release Planning with Product Backlog

To have a better understanding of release planning, you can visualize the release plans with the help of product backlog.

We already know the items in the product backlog are ranked or ordered, based on their priority. The top-level items which are fine grained, will be ready for consumption in the next iteration (under the immediate next release). The prioritized backlog, with features and other items, is shown on the left side of the figure below.

Within MS Project, you simply have to select, drag, and drop backlog items and arrange them as per your need to prioritize them. This is shown on the right side of the figure above. Considering previous example showing product backlog within MS Project, we have this relative ranking: first “Log into the online trading system,” next “Create a new user,” then “Buy a stock,” etc.

As shown above, I’ve selected and dragged the feature item “Log into the online trading system” and dropped it ahead of previously feature item “Create a new user.” The item selected was slightly greyed out as I dragged and dropped it.

Using the backlog, you can decide which of the backlog items should be delivered in the next releases. Below, we see that the items in next release (i.e. Release 1) are mostly prioritized. The items for Release 2 might be prioritized also, but we see that items for Release 3 are not prioritized as they are low priority items.

You can visualize this release planning with MS Project, as well. Look at the figure below. There are PBIs shown to be taken in various releases. Remember a release contains iterations? In our case, for the first release, we have three iterations, and all items are expected to be delivered in these iterations. An iteration is called a sprint in the Scrum framework, which is a popular framework used by Agile PMs. For the next two releases (i.e. Release 2 and Release 3), we have the PBIs, but we have not yet decided on the iterations (or sprints).

 

Iteration Planning

If you’ve followed, the release plan consists of Iteration 0 to Iteration N and we can decide to release at the end of every few iterations or every iteration. But, what happens within an iteration? Simply speaking, the scope for a set of features within the iteration is confirmed at the beginning of the iteration and delivered at the end of the iteration.

The features that are confirmed and taken for the iteration are broken down to tasks (or activities) and estimated in hours by the team members. The sequence of steps from product roadmap to release plan to iteration plan is shown in the diagram below.

Summarizing the above figure, these will be the key points:

• The product’s vision drives product roadmap
• Product roadmap drives release plans
• A release plan will have iterations
• Features, which are estimated in story points, are developed in an iteration
• Features are broken down to tasks, which are estimated in hours

Using MS Project 2016, you can build a release plan quickly. Considering our previous backlog example, we have three iterations/sprints for the first release (i.e. Sprint 1, Sprint 2, and Sprint 3). Each sprint has a set of features to be delivered. This is shown in the below in the “Sprint Planning Board” view.

You can also drill down to see what happens at the iteration/sprint level and find out which PBIs are being worked upon. MS Project shows this in “Current Sprint Board” view. See the figure below.

For Sprint 1, we have three items to be delivered – “Log into the online trading system,” “Create a new user,” and “Buy a stock.” These are passing through three the workflow states of “Next Up,” “In Progress,” and “Done.” Of course, you can add, remove, or customize these workflow states as per your need.

 

Release Plan Vs. Iteration Plan

If you are taking the exam, you also need to know the differences between Release Plan and Iteration Plan. They are noted in the table below. Typically, the iterations are timeboxed for two to four weeks. However, in some cases, such as XP (another Agile framework), iterations can be one week long.

 

References

[1] Project Management Body of Knowledge (PMBOK) Guide, 6^th Edition, by Project Management Institute (PMI)
[2] I Want To Be A PMP: The Plain and Simple Way To Be A PMP, 2^nd edition, by Satya Narayan Dash
[3] I Want To Be An ACP: The Plain and Simple Way To Be An ACP, by Satya Narayan Dash
[4] Microsoft Project 2016 Live Lessons, by Satya Narayan Dash
[5] Agile Practice Guide, by Project Management Institute (PMI)