4squareviews

This is a continuation of a discussion based on Chapter 5 (Implementing Agile) from the Agile Practice Guide, a publication jointly produced by the Project Management Institute and the Agile Alliance.

In the previous posts, I compared measurement of a project’s progress in a traditional vs. an agile environment.    A traditional measurement system such as Earned Value Management measures work completed; an agile measurement system measures work completed and delivered to a customer.    So it includes what in a traditional project management scheme consists of the following processes

• Process 8.3–Control Quality (internally verifying that the work conforms to the quality standards for the project)
• Process 5.5–Validate Scope (externally validating with the customer that the work conforms to the requirements for the project)

In other words, you measure whether the work is complete in a traditional measurement system; you measure whether the work is correct in an agile measurement system.

Two of the common systems for measuring progress on a project in an agile environment are a burndown chart and a burnup chart.   The raw data for both types of charts is the same, the number of story points.   The number of story points is an estimate of the effort required to complete a particular user story (feature) from the feature backlog.   The difference between the two types of chart is simple:

• a burndown chart starts with the total amount of story points expected to be completed in the course of a project, and as each user story is completed, the chart shows the remaining story points
• a burnup chart starts at zero, and as each user story is completed, the chart shows the completed story points

At the end of the project, a burndown chart will show zero remaining story points, and the burnup chart will show the number of story points completed for the whole project.  For examples of these graphs, see Figure 5.1 on p. 62 and Figure 5.2 on p. 63 of the Agile Practice Guide.

In a traditional project environment, the baseline may change if there are any changes to the scope during the course of the project.   Similarly, in an agile environment, if the scope changes during the iteration, the burnup or burndown charts will also change to accommodate those changes.

In agile, the velocity is a sum of the story points sizes for the features actually completed in the current iteration.    It is useful because, if the project continues at the current velocity of work production, you can take the number of remaining story points and divide by the velocity (number of story points done by each iteration) to get how many iterations it will take to complete the project.

It may take four to eight iterations to achieve a stable velocity.   After that, if the velocity changes, it will have a direct effect on the length of time it may take to complete the project, so it is important to measure velocity and compare it to the velocity of previous iterations so you can see whether there is any changes (up or down).

Now, the description above applies to iteration-based agile measurement.   If you use flow-based agile measurement, which does not use the regular cadence of an iteration, it is based instead on the completion of a particular user story or feature.   The next post will go into further detail into the flow-based agile measurements of cycle time and lead time.

Filed under: Uncategorized |