Loading...
Quick Links

Agile Release Planning: Let’s Break It Down!

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 6th 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 6th 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, 6th Edition, by Project Management Institute (PMI)
[2] I Want To Be A PMP: The Plain and Simple Way To Be A PMP, 2nd 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)

Satya Narayan Dash
Written by Satya Narayan Dash

Satya Narayan Dash is a management professional, coach, and author of multiple books: I Want To Be a PMP, I Want To Be a RMP, and I Want To Be An ACP, as well as his latest one, I Want To Be A CAPM. With his leadership and guidance, over 1500 aspirants have successfully cracked PMP, ACP, RMP, and CAPM examinations – in fact, there are 80 documented success stories in detail on these certifications. Satya’s course “PMP Live Lessons – Guaranteed Pass or Your Money Back” has made many successful PMPs, and he has created new management paradigms, including Practical PMP, Practical RMP, Agile PMP, hands-on Agile-related courses, and his recently launched “CAPM Live Lessons – Guaranteed Pass or Your Money Back.” His web presence is at https://managementyogi.com, and he can be contacted via email at managementyogi@gmail.com.

 

Share This Post
2 Comments
  1. I am a program manager who manages system-level projects – software and hardware. And I develop and use a “schedule” plan to coordinate dependencies among the many org entities that mange diverse constraints – material lead times, dev lead time, budget plan, funding availability, third-party suppliers, project management schemes diverse across organizations, and many more. These pretty much manifest as dependencies at all levels of the program on feature availability, often driven by development sequencing, which drives and is driven by dates.

    In the article, “schedule” planning is portrayed as “Traditional” and fixed and only changed by “formal change requests”. In the article, when reality causes discrepancy at some level to the “schedule”, the schedule discussion is dropped in favor of “adaptive, Agile methodology”. I see this kind of description all the time and disagree. Why do we think we don’t update “schedule” plans adaptively, to reflect, accommodate, mitigate current issues? In fact, we structure schedule plans at a level to avoid brittleness as much as we can, as low-level tasks shift. Obviously as change happens, we will try to accommodate or mitigate shifts of low-level tasks first in order to prevent or minimize shifts to high-level schedule items that often affect the business plan. Isn’t this also “agile” and “modern”?

    The difference I see from descriptions of Agile planning by Vision, Roadmap, Iterations, Backlog et al (which I love), is quantification to dates and dependencies – a “schedule”. And high-level schedule dates are almost always important to business plan – product viability, profit, stock options, bonuses; and often a factor significant to organizational success or even survival. This is why we try to mitigate dates, to maintain dates critical to business.

    So why does adaptive lifecycle management need to be incremental and un-quantified? At a program level we really do need to predict product and dependency availability, and spending dates. As I see it, as described in the article, Vision and Roadmap and Backlog driving Release Plan, can be captured as a planning entity that identifies tasks, and can be quantified in time. There are always dependencies across development modules, and sequencing of deliverables on both sides of a dependency needs to be planned, maintained and mitigated as needed. Backlog and release iteration planning are certainly involved in cross-module dependencies, and priority is affected significantly by dates (incorporating dev lead times and sequence) among supplier dev orgs and dependent dev orgs.

    My net is that a schedule reflects our best due-diligence view of how a program will develop, so that we can manage cross-module dependencies, spending, and overall meet the business plan. The schedule plan, and all levels of planning that drive it, are adapted all the time to reflect or mitigate changes so that we can best meet the business plan including its dates. Sometimes we can’t fully mitigate that and have to change the spending plan, or perhaps positioning of the developed product, or even cause change to the organization. This all seems “agile” to me – including use of dates.

    Reply
  2. Thanks Richard for your comment.

    Agile (adaptive) is both iterative and incremental as documented here and given as a link (previous article). Iterative means you will have dates. Perhaps you missed the iterative part.

    Agile approaches not only quantify from dates perspective, but also has other aspects – what to be delivered (scope is fixed at the beginning of the iteration and delivered at the end of the iteration), why to be delivered (business value which prioritizes the PBIs), how to be delivered (PBIs are broken into tasks at the beginning of the iteration), and of course, when to deliver (timeboxing).

    Now, release contains iterations and hence it also will have dates and what are expected to be delivered. The last table specifically informs on possible timelines for both release and iterations.

    When we do planning with WBS, it is usually highly predictive. There is rolling wave planning in certain cases and that makes planning to some extent adaptive, though still remaining overall predictive. In such a case, continuum of various life cycles comes up, which has been elaborated in the earlier article – Why and When To Go For Agile Life Cycle.

    Finally, as noted in the article, plan is needed (schedule/dates, scope, cost, resources etc.), but we can’t really stick to a plan, when changes are high. The agile manifesto also notes after the final value – “Responding to change over following a plan”, where it says: “while there is value in the items on the right, we value the items on the left more”, i.e., plans are valued, but responding to changes is valued more. Agile approaches work well in certain environments. It doesn’t mean traditional/plan-driven/highly predictive approaches are to be discarded, because they also work well in certain environments.

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please complete this equation so we know you’re not a robot. *

Thanks for submitting your comment!
You must be logged in to comment.