In this series of blog articles, we will cover three separate topics around release planning:
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.
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:
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.
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.
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
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
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:
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.
In Part 1 of Release Planning, we have discussed:
In Part 2 of Release Planning, we will go into the details for:
We hope that you have enjoyed this article and found it valuable.
Thank you, David Annis.