To model the iterative and incremental nature of an Agile project, we must repeat the process described above in several builds, within several releases, and with a fluctuating Product Backlog. Since, as described above, the transition of tasks (quantities of work) from one backlog to the other is time/event based, we need signals indicating the start and end of release and sprint cycles, to trigger the transition of work.
Figure 42 shows the model structure used to generate the Start of Release Cycle Event and the End of Release Cycle Event signals observed in Figure 43. The number of Planned Releases and the length of the project (equal to FINAL TIME) are used to calculate the length of a release cycle. “InRelease” is a control flag that is helpful in other parts of the model, used in a Boolean fashion to indicate if we are currently within a release cycle or in between cycles. In our model we have set the project length to 104 weeks (FINAL TIME = 104 weeks), with 4 planned releases (Number of Releases if Agile = 4), and half planning week in between releases (Release Planning Duration = 0.5 weeks).
To support the behaviour of a waterfall project, we also introduce the Switch for Waterfall control, which if set, causes the Release Cycle Duration to equal the duration of the entire project (this simulates a single-pass waterfall development approach.) We can thus generate events to drive a multi-release or a single pass development lifecycle by simply switching on/off this control.
With the parameters described above, and with the waterfall switch set to “off”, this results in a 26-month Release Cycle Duration as can been seen in Figure 43. On the other hand, turning on the Switch for Waterfall results in the single-pass release cycle shown in Figure 44.
A similar structure (seen in Figure 45) is used to generate sprint start and end events (seen in Figure 46):
If we execute our model with all of the above, while monitoring the flow of work in our three backlogs, we observe the behavior shown in Figure 47: at the start of a release (Start of Release Cycle Event), a set of tasks (Release Size) is moved from the Product Backlog to the Release Backlog. At the start of a sprint (Sprint Start Event), an amount of work (Sprint Size) is moved from the Release Backlog to the Sprint Backlog. As work is performed, tasks are consumed from the Sprint Backlog.
In Figure 47, the top line represents the Product Backlog: we observe it decreasing at the beginning of every Release The middle line is the release backlog, which decreases by small amounts at frequent intervals (the Sprint Duration). Finally, the almost imperceptible (at this scale) line at the bottom represents tasks in the Sprint Backlog.
To emulate a single-pass waterfall project, we employ the Switch for Waterfall control to simply set the sizes of these three backlogs to an equal value, thus executing one big one big release with a set feature list. The effect of this can be seen below in Figure 48.
