Executive Summary

In this series of blog articles, we will cover three separate topics around release planning:

• What is a Release?
• Details of the Release
• The Release Plan & The Cone of Uncertainty
• Key Performance Indicators / Charts to Measure for a Release
  

For both Technology and Business Executives these three topics are important to understand, so that the organization can plan appropriately and ensure that the technical team can be successful.

‍

What is a “Release”?

A Software Release consists of a collection of New Features, Bugs or Defects, which are tested and ready for deployment in a Production Deployment over a period of Time using an amount of Resources (money and Personnel). Within Software Development, we tend to define a given Software Release, by the amount of new Features or Bug Fixes that the software contains:

Major Release

This is a release that is focused on either a major overhaul of an existing Application, or a brand new Application. It is comprised of new features and functionality.

Example:  Windows 10.0.0.0

A Major Release represents a significant investment for the organization and requires a lot of time and resources. In addition, one would normally go through multiple Beta Testing cycles both internally and with a select group of external testers, before releasing the software into Production. This is critical, as with a Major Release, you are either changing or creating from scratch a lot of features, which may or may not work exactly as you expected them to work.

Minor Release

This is a Minor Release, which contains normally a combination of some additional Features, Enhancements, Modules, as well as Bug or Defect fixes that were found from a prior Release.

Example:  Windows 10.1.0.0

A Minor Release frequently will involve a Beta Testing cycle prior to deployment in Production. Although this is sometimes optional. It depends upon the number of changes, how many Clients or Users might be impacted, etc.

Build or Patch Release

Most of the time with these types of Releases, we are dealing with either none or very few Feature Enhancements. Most of the work is going to be Defect / Bug Fixes that fix a set of problems in the Production Environment. These types of Releases rarely if ever have any sort of external Beta Testing, although they often may have a round of User Acceptance Testing.

Example:  Windows 10.1.1.0

Emergency Patch Release

This is where a Critical Defect or Bug was found in Production that is causing severe issues and must be fixed immediately. It can’t wait for a normal Release Schedule. And in larger Software Companies, this would be handled by the Tier-II Support Engineering Team.

There is no External Beta Testing cycle, and frequently there is also no User Acceptance Testing cycle as time is of the essence, and the Patch must be deployed as quickly as possible. This means that there is a risk of breaking something else, but the risk of not deploying the Emergency Patch is determined to be greater.

Example:  Windows 10.1.1.1

The “Golden Triangle” of Negotiating a Release

For every Major and Minor type of Software Release there are 3 key Factors in determining the overall Plan for the Release. The “Golden Triangle” for Planning these Releases includes:

• Scope - What we Need to Build?
• Resources - What we are willing to Invest in Money / Resources (i.e. Budget)?
• Time - When do we Need it to be Done and Go Into Production?
  

The Business Team or Client can Pick any 2, but Only 2 of these Factors.

The Software Development / Implementation Team gets to Decide the 3rd Factor.

For example:

• If the Client determines the Scope and Time, then the Technical Team sets the Cost (Resources).
• If the Client has a fixed Budget (Resources) and Time, then the Technical Team gets to define what is Included in the Scope.
• If the Client wants a set Scope and has a fixed Budget (Resources), then the Technical Team gets to define how long it will take (Time).
  

Under no Circumstances can the Client (Internal or External) define all 3 Factors. As this will only lead to the Failure of the Project.

‍

Conclusion

In Part 1 of Release Planning, we have discussed:

• What a Software Release is
• The different Types of Software Releases
• And the “Golden Triangle” for Negotiating what is in a Release
  

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

• Defining the Scope
• Estimating Resources
• Determining a Team’s Velocity
• Developing your Time Estimates
  

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

Thank you, David Annis.