This final part of Iterative Solution Planning (ISP) provides template summary timelines suitable to the most common Release cadences. ISP design is based upon the assumption that in all cases, Sprints will have a fixed, 2-Week period. Thus, the cadence of Sprints is not in question. It is merely the number of Sprints to include within a Release which is to be determined on the Solution-by-Solution basis. If using a period for Sprints other than 2-Weeks - which is not advised - then adjust the aggregates described below.
While it is possible for a Solution to have a bi-weekly Release cadence (i.e., every 2-Weeks), it is important to note that doing so effectively removes the most important level of iterative management - Level 3: Releases. By establishing that each Sprint comprises an entire Release, some odd things occur. For example, Features and Stories will both have to be sized quite small. This will increase the number of Features required for a given Solution, along with the amount of management and refinement required. Though it may appear as if they are redundant, even if 1 Sprint = 1 Release, it would be a very bad idea to eliminate Features and to only use Stories. Without Features, managing up (across Solutions) and down (within each Solution) both become more complicated, challenging and time consuming. For example, attempting to map either Epics or Stories to things like Capabilities, Business Processes or Technology Enabliers introduces a variety of unhelpful, non-value add, work-arounds.
At the other end of cadence size, allowing more than one Quarter (3 Months) to pass before the next Release of a Solution starts to negate many of the benefits associated with Plan > Do > Check > Act cycles which are at the heart of iterative delivery. Excessivly long release scheduls impede the ability to provide frequent, new business value and adjust to changing business needs. The also degrade the ability to identify problems and quickly enact solutions. Most importantly, the desired flexibility of incremental delivery becomes less achievable the longer each iteration lasts.
Based on this guidance, the sections below look at the most plausable options for Releases which take at least 2 Sprints, but no more than 6 Sprints.
After reviewing the content on this page, check out the additional information on the following topics:
Alternative Timelines for Solution Delivery
Each Solution is subject to its own cadence for short-term and medium-term planning. While there is no one right answer as to the proper cadence for a given Solution, the following should be considered when determining the cadence to apply:
- Solution complexity - the more complex, or unique, the solution the more benefit will be obtained by lengthing the Release cycle. Solutions which involve often repetitive work (e.g., server deployments) can benefit from shorter cycles.
- Solution type - Products, particularly COTS or SaaS applications, will often require some post-build window during which a steady-state, Candidate version of the next Release can be validated. The amount of time required for such validation determines the shortest achievable Release cycle. If Releases occur more frequently than the validation can process them, they simply begin to stackup, unverified, awaiting production deployment. This adds a tremendous amount of non-value add management overhead.
- Solution lifecycle - at the beginning of each Solution's lifecycle, there will be much to learn. And the tools and capabilities needed to manage the Solution will take time to put into place and become effective. Again, a longer Release cycle will be most helpful early in the lifecycle. As knowledge, abilities and tools improve, perhaps the Release cycle can be shortened.
Monthly Release
In this scenario the goal is to provide Customers with new features and functions every month (i.e., 12 time per year).  A Monthly Release cadence will include just 2 Sprint cadences in each Release. The following are some Pros & Cons for such a cadence:
Pros:
- Most frequent release of new functionality to Customers;
- Best suited to Solutions which involve frequently recurring work (i.e., repetitive, standardized tasks) or only minor changes.
Cons:
- A very mature delivery model must be in place and functioning well;
- Features must be relatively small in scope, thus more will be needed meaning more refinement and more management of these objects.
Bi-Monthly Release
In this scenario the goal is to provide Customers with new features and functions every other month (i.e., 6 times per year).  A Bi-Monthly Release cadence will include 4 Sprint cadences in each Release. The following are some Pros & Cons for such a cadence:
Pros:
- Still a relatively frequent release of new functionality to Customers;
- Best suited to Solutions which do not involve repetitive (i.e., simple) or complex (i.e., difficult) changes;
Cons:
- A mature delivery model must be in place and functioning well most of the time.
Quarterly Release
In this scenario the goal is to provide Customers with new features and functions every third month (i.e., 4 times per year). A Quarterly Release cadence will include 6 Sprint cadences in each Release. The following are some Pros & Cons for such a cadence:
Pros:
- Best suited to new Product Solutions, particularly those which are COTS- or SaaS-based;
- Allow for the broadest, and thus fewest, number of Features to achieve a given Solution. This minimizes associated management overhead;
Cons:
- Least frequent release of new functionality to Customers;
- Least amount of flexibility in mid-level (i.e., monthly) management.
Changing Release Cadence
It is possible to change the Release cadence of any Solution. However, this should be done only rarely, and should never occur on a Release-by-Release basis.
When to Change Cadence:
The proper time to change the Release cadence of a Solution is at the beginning of a new Phase. Once established for the Phase, the Release cadence should remain the same throughout. There should be no discussion or debate during a Phase about modifying a Release cadence. A major objective of iterative delivery is to eliminate time as a variable from discussions. Entertaining the idea of changing a cadence defeats that objective.
However, when shifting from one Phase to the next this is a topic which should be discussed. As a Solution evolves throughout its lifecycle there may be valid reasons to modify its cadence.
Some reasons to lengthen a Solution's Release cadence:
- The frequency or complexity of change is about to increase. Perhaps a new Solution is being introduced, or new functionality is being enabled in an existing Solution.
- There is frequent failure to achieve the current cadence. If delivery of Releases on the existing cadence is problematic, allow extra time in order to increase the probability of success. If a Monthly Release schedule is missed as often as it is made, then extend to a Bi-Monthly schedule so that all Releases can be delivered. This will reduce the non-value work-around efforts and allow folks to focus on actual value-add delivery.
Some reasons to shorten a Solution's Release cadence:
- The frequency of change is about to deminish. This may be due to the Solution Backlog running out of work to be done. Or it may be in response to a decision to reduce or eliminate funding for additional change. Either way, if less change is coming, that change can be handled in shorter increments of time.
- DevSecOps and/or Delivery Team(s) have achieved required abilities. In seeking continuous improvement there will be occasions where what used to take days or weeks, can now be managed in hours to days. When enough suitable improvements have been achieved, it may be appropriate to shorten Release cycles to make more functionality available on a faster schedule.