The middle of three (2 of 3) durations used to Organize Solution Timeframes is based upon Releases. These medium cycles, and their related activities, segment and manage Time on a Monthly basis.
Typically, each iteration spans a medium-term ranging from 1 to 3 months. Release related work is best suited for managing Solution progress, and for orchestrating work occurring on other, related, Solutions.
Alternatively, transformation participants who take shorter view will have more interest in Sprints; those who take longer views will have more interest in Solution Phases.
The medium-term duration introduces, and defines, the following terms:
- Release
- Release Cadence
- Release Planning Event (RPE)
- Release Backlog and
- Release Retrospective.
Medium-Term Timeframes
The headings below introduce terms which describe work to occur in the coming months.
Release
The next, or middle, time segment, is a grouping of Sprints called a Release. Each cycle consists of a fixed set of Sprints. Typically, each iteration includes between 2 and 6 Sprints.
To explain, at less than 2 Sprints a Release becomes the equivalent of a Sprint. In effect, this eliminates an entire time segment with which to plan and manage Solution progress. Additionally, this poses many challenges for those orchestrating change across multiple Solutions.
Alternatively, at more than 6 Sprints, a Release starts to lose many of the characteristics which make Iterative Transformation desirable.
Release Cadence / Schedule
Basically, Cadence refers to the cycle, or timing, of each iteration. Accordingly, after setting some number of Sprints within a cycle, it is vital that the number not change. To emphasize, the number of Sprints must remain fixed. Otherwise, the whole iterative model breaks. For additional information refer to Sprint Cadence.
The number of Sprints to include will depend on several factors, including:
- the Solution Type;
- where a Solution is in its lifecycle; and
- the Solution's complexity.
For instance, periods longer than a single quarter (3 months) do not lend themselves as well to flexibility. Further, they make alignment with other transformation efforts much more difficult.
The purpose of a medium, fixed amount of time is allow for another level of consistent 'Plan > Do > Check > Adjust' (PDCA) cycles. Accordingly, each iteration offers opportunities to learn from mistakes, to introduce improvements, and to accommodate shifting priorities after each cycle.
In particular, Products often benefit from longer Release cycles. Because, unlike Systems and many Services, most Products require a period of time to further validate changes made during the iteration. To explain, during the Release, change is ongoing. Only after reaching a steady state, once the cycle is complete, can such testing occur. Typically, the term for such additional testing is 'Certification' or 'Validation'. Generally, this extra period is to align changes with other, related Solutions. As a matter of fact, those related Solutions may also require a steady-state target against which to validate their own changes.
The amount of time needed to complete a validation cycle dictates the minimum Release Cadence. If the iterations occur more frequently than the ability to certify them, then Releases just pile up behind the validation process. More on this in the section on Solution Delivery Planning.
Release Planning Event
To begin, there is a ceremony prior to each Release called the Release Planning Event (RPE). In short, this is a ceremony because it is a ritual, observed on a regular basis, with specific procedures performed at each occasion. Hence, it is more than just a meeting.
Indeed, the RPE is the 'Plan' portion of the medium-term PDCA cycle. At this time, a Solution Manager (or delegate) will present a prioritized list of Features (only, no Stories or Bugs) needing work. Afterwards, the Team responsible will accept delivering some amount of that work. The amount they commit to is based on what the Team believes they can complete successfully considering, considering the time and resources available.
Eventually, the Release Manager will add the items which the Solution Manager and Team agree to tackle to the upcoming cycle's Backlog. Correspondingly, they will also add any Stories & Bugs which relate to the selected Features. If things are working well, then the amount of work a Team completes within each iteration should increase. That is, Teams should become more productive. Alternatively, if the amount of work is decreasing, that's an indicator that something is wrong. Further, it may indicate a need for corrective action.
Of course, these events occur prior to each cycle. Hence, every month or so, there is an opportunity to shift priorities and monitor the productivity of the delivery process.
Release Backlog
Generally, the Release Backlog is merely the list of items - Features, Stories and Bugs - the Team expects to complete during the upcoming cycle. That is, over the next one (1) to three (3) Months. In other words, it contains the work chosen during the RPE.
Specifically, this backlog is a subset of the Solution Backlog. Accordingly, each iteration creates its own, distinct Backlog, which Teams then work to clear during that iteration.
In effect, this backlog represents the 'Do' portion of the PDCA cycle. During the cycle, Teams work each Feature, Story, and Bug in the backlog. To rephrase it, Teams will create, configure, or update functionality related to each item.
The work to deliver each item also involves testing and approval. Of course, this represents the 'Check' portion of the PDCA cycle. Accordingly, the objective is to complete each item such that no expects any further work on it.
Once achieved, an item is "Done". In effect, it will move on, past the Release, towards production deployment. Thereafter, use new Features to extend business value beyond that already complete. Alternatively, any items not "Done" by the time an iteration ends, return to the Solution Backlog for work in some subsequent, later cycle.
Release Retrospective
At the end of each Release there is a ceremony called the Release Retrospective. This is a time for stakeholders to identify problems or improvement opportunities, to discuss options, and to select changes that are intended to improve future efforts.
This Retrospective covers the 'Adjust' portion of the PDCA cycle. 'Adjustments' can be made at this time for future iterations or may be introduced some time later once proper preparations have been made.
Ideally, improvements can be implemented in the next cycle, or one soon after. Implementing such changes is one of the primary reasons overall productivity is expected to improve over time using an iterative approach.
Non-Release Work
Important to realize, any Feature added to a Release Backlog must be in a "Ready" state. In other words, that means the Feature's Analysis & Design is already complete and approved. Conversely, it is acceptable to add related Stories & Bugs to a Release Backlog even before they are "Ready".
Moreover, while the Team executes tasks to make items "Ready" in parallel with each Release, such work itself is not part of a Release. Instead, it is preparation for some future cycle.
To explain, the reason for this is that prior to being "Ready", no one understands the business value sought, or the time and effort it may take to deliver.
However, by the time Features are "Ready", folks have a solid understanding of the effort required to complete each Feature. Thus, they can schedule Features appropriately within each iteration.
Further, the amount of time and effort needed to make a Feature "Ready" is also unknown. Accordingly, it is not practical to schedule such work into a specific window. Hence, Analysis & Design work does not belong in a Release Backlog.
For More on Releases
Look to the following for more information regarding Releases:
The next time iteration up from Releases describes Long-Term: Solution Phases.