Concept: My posts on AgileES have thus far focused on“what” and “why”. That is, I’ve described the concepts behind AgileES and the benefits of using ES on Agile projects. It’s now time to shift the focus to “how to”. The next posts describe how to apply ES to Agile projects. There are several steps. Some of the steps, especially the initial ones, are controversial. In explaining each step, I will identify and address the issues and then describe the actions to be taken for AgileES.
Practice:To manage schedule performance with AgileES, the second step is to set the schedule’s performance measurement baseline (PMB).
2. Baseline the schedule.
In plan-driven projects, the schedule baseline is a fixed sequence of deliverables linked by dependency chains. Each task and each chain cover specific time periods. In total, the time periods stretch from the beginning of the project to its end. Performance is measured by how well or poorly tasks are completed in accordance with the defined timeline and sequence.
In Agile projects, the Release Plan is sometimes thought to function in the same way. That’s a mistake. The Release Plan is not the schedule baseline. It is simply one path that goes from where the project currently sits to the completion of the Product Vision. At the end of each Sprint, the path may change as different Product Backlog Items (PBI) are selected for the next Sprint. [1]
Projects using a canonical Agile approach use past performance and business priority to guide the selection of Items for the next Sprint. Past performance indicates the number of Release Points that are typically completed during a Sprint—that is, the mean velocity. Each PBI is associated with a number of Release Points. So, the next Sprint’s PBIs are selected with the mean velocity in mind.
Projects using a canonical Agile approach stop there. After-the-fact performance analysis and forward-planning are limited to selecting PBIs for the next Sprint. [2]
AgileES projects, by contrast, cannot stop there. Time and budget constraints mean that estimating and planning must cover the whole project lifecycle. [3] This is achieved by using the velocity estimate to determine the number of sprints.
The number of sprints and the planned start determine the planned finish. With start and finish set, the Baseline Earned Schedule (ES) Burndown follows. In the ES Burndown, the time associated with one Sprint is earned for each elapsed Sprint. (See Figure 1.) The estimated velocity and its derivative, the Baseline ES Burndown, constitute the core of the PMB for AgileES.
Although estimated velocity is the chief input to the PMB, there are two other possible inputs: Contingency and Reserve. They act as buffers to change. Here, again, AgileES deviates from canonical Agile concepts.
In the Agile framework, change is welcome. It is viewed as an opportunity to better serve business needs. Without time or budget constraints, change is not perceived to add risk to the project.
In AgileES, change means potential deviation from timeline and budget constraints. Thus, change poses risk. Contingency and Reserve are used to manage the risk. [4]
The Contingency allowance is based on identified risks and responses. The amount typically falls in the 10-20% range. Contingency is controlled by the project team. Because it is tied to specific risks and associated responses, Contingency is included in the PMB.
Figure 1
Figure 1 is an example of the Baseline ES Burndown from a recent project. Later posts will explain how to produce and interpret the chart. As noted above, the ES Burndown is the PMB, and it can now be added that it includes Contingency.
Another possible input to the baseline is Reserve. The Reserve allowance is also based on risk analysis, but it is not tied to specific responses. The amount typically falls in the 5-10% range. Reserve is controlled by the Product Owner in consultation with both the project team and senior management. Because it is not connected beforehand to specific responses, Reserve is not included in the PMB. [5]
In AgileES, change is not ruled out. If it falls within allowances for risk, it can readily be adopted. If it exceeds those amounts, it can still be adopted, but only with a significant alteration of the project’s committed timeline and budget.
References and Notes:
[1] The fungibility of Product Backlog Items means that equivalent items can be substituted for one another. In practice, pure fungibility is difficult to achieve. Conceptually, however, fungibility undermines the notion of a fixed sequence of interdependent tasks. In short, because of fungibility, you cannot count on there being a fixed sequence.
[2] Both the Agile Manifesto and Agile Principles embrace change without conditions on time or cost. In the absence of time and cost constraints, estimating and planning the project need not go beyond the next Sprint. See Agile Manifesto, Agile Principles, and Agile Alliance Glossary entry for Velocity.
[3] For more information on constraints, see the previous post on Step 1: Estimate Velocity.
[4] Risk comes from uncertainty. For simplicity, the discussion here is solely in terms of risk. For a more robust treatment of risk and uncertainty, see Alleman, G.B. Performance-Based Project Management. New York: Amacon. 2014, pp 52-54.
[5] There are other possible allowances for uncertainty and risk, e.g., Margin. For simplicity, they are not included here. For details, see Alleman, G.B. Performance-Based Project Management. New York: Amacon. 2014, pp 52-54. |
