December 11, 2020

Software Release Planning - Part 3

We talk about Agile software development process and about predicting the Cone of Uncertainty for your Release Plan and Creating Your Phase / Milestone Plan.

Executive Summary

This is Part 3 of our Release Planning blog posts series, click here to go to Part 1 and Click here to go to Part 2.

In Part 3 of Release Planning, we will go into the details for:

  • Predicting the Cone of Uncertainty for your Release Plan
  • Creating Your Phase / Milestone Plan

software development process

Release Plan

Coming up with a Plan for an Upcoming Release and more importantly its timing, is very similar to trying to accurately predict the Path of a Hurricane. It’s not easy and you will never be 100% accurate early on. Especially with a large project there are a lot of different variables, which will impact the actual timing of the Release.  Some of these you can predict and control, while others are external variables that will affect the path of your Release.

Predicting the Path of a Hurricane

Anyone who has watched the news of an approaching Hurricane has seen this type of diagram from NOAA.

path of a hurricane

This is known as the Cone of Uncertainty, as we know with 100% accuracy where the Hurricane is at this very moment. However, as we go further out into the future, we become less and less certain as to the exact path that the Hurricane may take. And because of this the “Cone” becomes larger and larger the further out in time we go. You can easily see this in the chart above.

The most important aspect of Predicting the path of a Hurricane is to constantly update this “Cone of Uncertainty” as new facts and information are reported. For an organization like NOAA they might do this every hour, moving their Predictive Model further out, as the Hurricane moves. This way as the Hurricane moves slightly to the right or left of its Predicted Path, they update the Predicted Path and the future “Cone”. This provides everyone with the latest information as to where and when the Hurricane may make landfall.

The Cone of Uncertainty in a Release

This same process occurs in Software Development. During the course of the Project we only really know where we are at right now. The rest is a Prediction, and the farther out we are trying to Predict the wider our “Cone of Uncertainty” will be. And likewise, the shorter the Timeframe that we are trying to Predict, the tighter our “Cone of Uncertainty” is.

agile software development process

Break Things Down Into Phases

Just like you break down the Scope of a Project into multiple Modules and Epic Stories, etc. You can break down your timeline into separate Phases or Milestones, each with separate Themes and Timeframes.


  • Phase I:  Create Request For Quote Module
  • Phase II:  Create Quote Module
  • Phase III:  Create Purchase Order Module
  • Phase IV:  Create Sales Order Module
  • Phase V:  Create Invoice Module
  • Phase VI:  Internal BETA Testing
  • Phase VII:  External BETA Testing
  • Phase VIII:  Release to Production

This way you can now start to line up the Timeframe, Resources and Scope for the first 2 Phases. What does each Phase include (Scope)?  When does it need to be done?  And what Resources are needed?

software development process model

Only Predict the Next Phase (If Possible)

Given the “Cone of Uncertainty”, if we are trying to determine the exact Date for Phase VIII completion, we will never be accurate. Where possible try to focus your efforts on Predicting one or maybe two Phases in Advance, because those are going to be the most Accurate. Anything beyond that has a high risk of changing.

However, most Business Executives and Organizations will want some idea of when the Project might end. So, in these case do the following:

  • For Future Phases that are One or Two Phases Out - DO NOT GIVE A SPECIFIC PREDICTED DATE
  • Only Present a “Cone of Uncertainty” Range
  • And similar to a Hurricane Model, you probably want to do something like this:

Example:  Request For Quote Module - Release Plan

Using our Previous Example from Part 2 - Scope and Timeframe:

  • Request For Quote Model - Scope is expected to be 6 Epic Stories
  • 260 Base Points
  • Risk Factor of 20% to 50%:
  • Unknowns, Scope changes, additional QA testing, etc.
  • Total Points 312 to 390
  • Resources = 10 Resources (from above)
  • Estimated Velocity = 75 Points per Sprint (2 Week Cycle)
  • Conservative Velocity = 60 Points per Sprint
Estimated Time of Delivery (Development)
  • Best Case Estimate = 312 / 75 = 4.16 Sprints
  • Rounding to the Next Whole Sprint = 5 Sprints
  • 10 Weeks of Development Effort
  • Worst Case Estimate = 390 / 60 = 6.50 Sprints
  • Rounding to the Next Whole Sprint = 7 Sprints
  • 14 Weeks of Development Effort

Note:  this is an example only of how to do this, but is based on experience or similar projects.

agile software development process
software development process model

Notice that your Cone of Uncertainty grows over time. So, at the beginning the gap is very small, and as you get to Phase IV - Production SaaS Deployment the Cone is nearly 2 Months Wide. This could even be wider, depending upon the Risk Factors involved with the Project and how many changes / unknowns you are expecting.

Don’t Spend Time on a Detailed Gantt Chart for a Large Project (6+ Months)

In a Traditional (Planned) Project Management Methodology the Project Manager(s) will spend a lot of time creating and updating a very detailed Task level Gantt Chart, which is constantly changing. However, due to the “Cone of Uncertainty” in Developing Software, we must ask the question, “Why are we doing this?”  Especially for large projects that are going to take 6+ months or more.

We know that we are going to encounter Changes and Unexpected Impediments throughout the lifecycle of the Project. And if we know we can only Predict out 2 to maybe 3 months with any reasonable Accuracy, then why spend the time and effort on a Detailed Gantt Chart showing say 18 months worth of Tasks?


Every Technology Executive and Professional knows that if you’re trying to Predict that far out, it is going to be wrong. It is creating an illusion that we know when the Project will be completed. And worse we are setting ourselves up for failure. Because if we report to the Executive Management team that based on what we know this Project will be done by X Date Range, then that becomes the Timeframe, regardless of what happens. That is the date they will remember and hold us accountable to.

software company personal story

Personal Story

In 2016, I was the VP of Software Development for a small Software Company, although our actual Development organization actually consisted of two separate teams. Product Management oversaw one of the teams, and I oversaw our core team.

While our Core team was working on other Products, the Product Management team was asked to do a refactor of the User Interface of our main Product to replace Microsoft Silverlight, which was being deprecated. They didn’t like using an Agile framework and so created a very detailed Plan and Gantt Chart showing what they thought was every task that would need to be done. And they Predicted, based on their Plan, that they would be able to have a Production Release in six months.

They were wrong, it actually took closer to 18 months. Unfortunately, the Executive Management Team believed them, because of how detailed their Plan was. They assumed (incorrectly) that because the Plan was so detailed that everything was absolutely included in the Plan, and that we were, “Trying to Boil the Ocean” with our concerns.

And based on this, the Sales Team was given the “Green Light” to start Selling the new version of the Product after the first 3 months had passed. And like every other Software Company who has tried to sell “Futures” or “Vaporware”, it normally doesn’t end well. Because at some point the Client who bought the Vision of the Product, actually wants to use it. And that is when your Professional Services Team comes back and says, “It doesn’t work, we can’t implement this.”

My strong recommendation is if you are actually selling a Software Product, wait until it is in an External BETA Stage and you have at least some initial feedback that Customers actually like it.

Then you can go out and actually Sell the New Product. Otherwise, you will get too far out in front of your Skiis and quite probably crash and burn.

software development process


In Part 3 of Release Planning, we have discussed:

  • Predicting the Cone of Uncertainty for your Release Plan
  • Creating Your Phase / Milestone Plan

In Part 4 of Release Planning, we will go into the details for:

  • Measuring the Progress towards your Milestones and Release
  • Warning Signs to look for

If you haven't, you can check Part 1 here, and part 2 here.

We hope that you have enjoyed this article and found it valuable.

Thank you, David Annis.

Case Study from Arkusnexus
David Annis
David is a VP and Agile Coach within ArkusNexus, having served in multiple CIO, VP of Software Development roles. He assists our Sales, Marketing, and Operations Teams on critical initiatives.
RSS feed
Subscribe to our feed
Back to More ContentMore From this Author

3065 Beyer Blvd B-2
San Diego CA 92154 - 349

mind hub tijuana