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: AgileES is a lightweight process. It requires no data collection beyond what is normally done for an Agile project that is constrained by time. Calculating the metrics takes additional effort, but the increment is virtually eliminated by using a tool.
3. Capture Performance Data.
The routines for collecting performance data vary from project to project, but the best practices we have observed are as follows.
- Collect data continuously during a Sprint, rather than at the end of a Sprint.
- Count the number of Release Points that have been completed during the Sprint.
- Add new Items identified during the Sprint to the Product Backlog.
- Add new Release Points identified during the Sprint to the total count.
- Remove all Product Backlog Items and Release Points that are no longer required.
4. Calculate the Metrics.
The calculations are generally done at the end of each Sprint and results are stored across Sprints to facilitate trend analysis.
Here are the calculations used by both Agile and AgileES projects that operate under constraints:
- Planned Value and Earned Value: Historically, these are referred to as Budgeted Cost of Work Scheduled (BCWS) and Budgeted Cost of Work Performed (BCWP). The Cumulative Planned Value (CPV) equals the Planned Release Points (PRP) multiplied by a relevant Rate (Rk). The Earned Value at the Actual Time (EVAT) equals all Release Points Completed (RPC) by the Actual Time multiplied by a relevant Rate. [1]
- Estimated Completion Date for counts: This is also known as the estimated Release Date given the expected velocity (RDv). It equals the Start Date (SD) plus the sprint length (L) multiplied by the number of sprints (n) divided by the Actual Per Cent Complete (APCn).
- Baseline Release Points (RP) Burndown: For each Sprint, the number of Release Points remaining given the total number of Planned Release Points less the planned velocity (vp). When charted, the Baseline RP Burndown shows how much planned work should have been completed and, by inference, how much remains on the project.
Graphically:
Figure 1
-
Actual Release Points Burndown: For each Sprint, the number of Release Points remaining given the total number of Planned Release Points less the actual velocity at Sprint n (vn). When charted, the Actual RP Burndown shows how much planned work has been completed and, by inference, how much remains on the project.
Graphically:
Figure 2
Here are the calculations used specifically by AgileES:
-
Baseline Earned Schedule (ES) Burndown: For each Sprint, it is the number of Sprints remaining given the total number of Sprints less the number of Elapsed Sprints. [2] When charted, the Baseline ES Burndown shows how much of the timeline should have been completed and, by inference, how much remains on the project.
Graphically:
Figure 3
-
Actual ES Burndown: For each Sprint, the number of Sprints remaining given the total number of Sprints less the number of Sprints (or portions thereof) completed, i.e., less the Earned Schedule. When charted, the Actual ES Burndown shows how much of the timeline has been completed and, by inference, how much remains on the project.
Graphically:
Figure 4
When differential rates are applied to Release Points, the ES Burndown can vary significantly from the RP Burndown. A recent project provides an example.
First, Figure 5 shows the Release Point Burndown. The “bulge” at Sprint 8 occurred when Reserve was released. Reserve is not part of the Baseline but omitting it made the chart inaccurate: either the new Release Points were not shown or the burndown went into negative numbers. Here, it is included as part of the project commitment.
Figure 5
Next, Figure 6 shows the ES Burndown when a single rate is used to value all Release Points. Note how it follows the Release Point Burndown for most of the project. It varies only at the end. Again, that is when Reserve was released. The release is reflected in the extension to the timeline.
Figure 6
Finally, here is the ES Burndown when different rates are applied to Release Points. In the real case, the rates varied by the resource assigned to complete the Release Points. There is an obvious “bulge” at Sprints 3-5, indicating that time was not being used efficiently.
What happened? In an effort to maintain the planned velocity, the team completed Release Points that were quick to finish but of relatively low value. That move sustained the Release Point velocity but lost schedule efficiency (as measured by value).
Figure 7
[1] On many Agile projects, a nominal Rate of $1 is appropriate. If so, the committed PRP total and the CPV will match, as will the RPC and EVAT. There are cases where variable Rates are a better fit, and when this occurs, metrics can be significantly affected. For more information on differential Rates, see the previous post on ES and Agile differences. Finally, do not mistake Earned Value for Business Value. EV is a measure of performance efficiency. BV is a measure of performance effectiveness. For more information, see the aforesaid post.
[2] The total number of sprints is determined by the total number of release points divided by the estimated velocity, i.e., by the estimated number of Release Points per Sprint. |
