ProjectFlightDeck

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. 

Practice:The most consequential question we ask in each Sprint planning session is this: do we have to set a new baseline? Re-setting the baseline is a non-trivial response to schedule deviations. It has significant ramifications, both practical and political.

7. Re-baseline

For plan-driven projects, the baseline against which we measure performance (the PMB) consists of fixed sequences of deliverables linked by dependency chains. The chains occupy specific time periods. As a whole, the time periods cover the project timeline from start to finish.

The Agile PMB is a different story.  Agile project teams are free to identify each Sprint’s content within velocity constraints. [1] So, it is no longer necessary to have fixed sequences of deliverables, static networks of dependency chains, and a definitive path from the start of the project to the end. What takes their place is the Baseline ES Burndown.

Previous posts describe in detail how the Baseline ES Burndown is determined. A summary is included here.

Figure 1

In short, the ES Baseline is one Sprint earned for each elapsed Sprint.[2] That is a sufficient basis to measure how time is being used on the project.

Agile welcomes change. For Agile projects bound by time and cost constraints, change creates uncertainty and, consequently, risk. In planning the next Sprint, you must always ask: is the baseline intact? Have the changes that occurred during previous Sprints undermined the PMB? Must a new baseline be set?

When is re-baselining required? AgileES provides a robust set of metrics to help answer the question. In practice, we focus on the following four: Burndown, SPIt, ECDt (or EACt), and Rate of Discovery. From among the actions identified in Step 6, the ones we watch most closely are threshold breaches and trends.

For setting a new baseline, the rule-of-thumb we use is the following [3]:

Figure 2

The rule-of-thumb is more than just a theory. We use it in practice. The project that has served as our example in previous posts on AgileES is one such case. Until now, we have simplified the example somewhat for ease-of-understanding. From this point forward, we will use the actual parameters.

At the start of the project (call it Project A), the parameters were as follows:

Figure 3 below was the chart used in Sprint planning sessions. The snapshot was taken at the end of Sprint 3.

Figure 3

After Sprint 1, the project was behind, but the lag was attributed to uncertainties common to starting up a project. The team did not take remediating action at that time.  When Sprint 2 showed a similar result, the team started root cause analysis of the deviation.

By Sprint 3, the gap between the ES Burndown and the Baseline ES Burndown was noticeable and growing larger with each Sprint. The graphic gave the impression that there was a problem, but how serious was it?

We used the following “chicklet” table to clarify the severity of the situation. It contains detailed metrics from each Sprint with the status indicated by threshold values. (See previous posts for details on threshold values and status flags.)

Figure 4

The SPIt hovered around .20—deeply in the range considered “Red”.  The number of PRPs being added had increased to over 5000—that was a jump of more than 35% over the original baseline. And, the EACt stretched far beyond the planned duration—it was about 150% of the target date.

The threshold breaches on both the SPIt and EACt were sufficient to warrant a re-baseline. Investigation of the trend showed that Release Points were being completed at a velocity much lower than expected. But, that was only part of the story. Root cause analysis identified the real source of the problem.

The number of points being added far exceeded allowances in Contingency and Reserve. Some of the new points came from elaboration and were accommodated by Contingency. Far more new points were due to the addition of net new functionality. Unexpected changes in the business environment had caused a rapid expansion in the scope of the project.

Clearly, a new baseline was required.

As Walt Lipke once said: “new baseline, new project”. [4]  The first step in setting the new baseline was to freeze the old one. Metrics from completed sprints were retained for historical purposes. (The time and budget consumed had to be included in the overall project accounting.) Unfinished points that were still required and new points that were added constituted the pool of Release Points for the new baseline.

The velocity estimate was revised, along with required changes in staffing and budget. In the example, the influx of new points necessitated an expansion in both team size and budget. The risk analysis was updated and, consequently, the Contingency allowance was modified. Reserve was also reviewed and revised. Based on these changes, the budget was refreshed, project dates were reset, and a new Baseline ES Burndown was produced.

Here are the revised parameters for the example.

The new Baseline ES Burndown is depicted below in Figure 5.

Figure 5

The final "how-to" step describes the way a new baseline is used to steer the project. Before tackling that topic, let's look at the impacts of setting a new baseline.

Notes and References