4squareviews

This is a continuation of the discussion of section 5.4 Measurements in Agile Projects of the Agile Practice Guide.

Measurement of the progress in doing a project is different between traditional and agile projects.   Traditional projects used Earned Value Management, which takes the unit of measurement to be the number of dollars (or whatever currency the organization is using) budgeted for the completion of a work package.

There are basic building blocks to the measurements in Earned Value Management.

• Planned value (PV)–this is the authorized budget assigned to the work that is scheduled to be done.   (The key word there is “scheduled”.)
• Earned value (EV)–this is the measure of work actually performed.   (The key words there are “actually performed”–it is a a measure of how much scope was accomplished.)  This is expressed in terms of the budget authorized for that work.
• Actual cost (AC)–this is the measure of the actual cost for work actually performed.  (The key word is obviously “cost”.)

To get the Cost Performance Index, you take AC/EV, and to get the Schedule Performance Index, you take EV/PV.

In agile, the unit of measurement is a story point, which is an estimation of how “big” the user story (i.e., a feature of the product being created) is.   It is a relative estimation, so the size of the smallest feature may be designated arbitrarily as 1, and the other features given a number of story points in comparison.

When I was initially studying about agile, I thought that Earned Value Management wouldn’t be used, but an analogy can be used in an agile environment.   For example, an analogy of the Schedule Performance Index can be used.  SPI in a traditional project environment would equal

SPI = EV/PV = (value of work actually performed)/ (value of work planned)

Since PV and EV are both in units of dollars, you get a simple ratio as a result.   An SPI of 0.80 tells you that your team only got 80% of the work done.   Analogously in an agile environment, if you take SPI now to mean

SPI = (number of story points actually completed)/(number of story points planned)

then you can compute the SPI for a given iteration.   If you planned on completing 20 points in an iteration, and the team actually only completed 15, then the SPI is 15/20 or 0.75.

However, one of the main differences between EVM in a traditional vs. agile environment is the following.   In traditional EVM, earned value or EV refers to the work completed by the team.   However, EV in an agile environment refers to work that is not only completed by the team, but shown to the customer and validated that it conforms to their understanding of the requirements.   Because if it does not conform, then the item or feature has to be reworked.   It is not just work that is complete, but work that is also correct, that counts in agile EVM.

Now there are two ways of setting up iterations in agile.   One is take an arbitrary amount of time (usually referred to as a timebox) and then you take a measure of your progress every two weeks or however long the iteration is.   The team following this approach is referred to as an iteration-based agile team.

There is another way of marking progress, and that is having the iteration not be specific length, but the length of time is takes to do the next feature in the product feature backlog.   The team following this approach is referred to as a flow-based agile team.

The measurements used with flow-based agile teams are listed below in relationship to a Kanban board.  The “ready” column on a Kanban board is the list of features from the product feature backlog that are ready to be worked on, usually the left-most column.  When the item is ready to be worked on, it is removed from the “ready” column and put in the development column to its right.

• response time (the time that an item waits in the “ready” column until the work starts)
• cycle time (the time that it takes to process an item once the work starts)
• lead time (the total amount of time it takes to deliver an item, from the time it is added to the board in the “ready” column to the moment it is completed)

As you can see from the above definitions, the lead time is equal to the response time plus the cycle time.   The cycle time measures the work in progress.

According to the Agile Practice Guide, the cycle time can be used by a flow-based agile team in order to see bottlenecks or delays, whether they are inside the team or external (based on interactions with the customer or sponsor, or perhaps caused by delay of delivery of resources from a vendor).  The next post will talk about a cumulative flow diagram, a way of representing the measurements listed above, which can give clues as to the source of those delays.

Filed under: Uncategorized |