A blur!

I was recently asked to explain the difference between a number of metrics.  One difference that seems to generate some confusion is that between velocity and cycle time.

Velocity:

Velocity is one of the common metrics used by most Agile teams.  Velocity is the average amount of “stuff” completed in a sprint.  I use the term stuff to encompass whatever measure a team is using to identify or size work.  For example, some teams measure stories in story points, function points or simply as units. If in three sprints, a team completes 20, 30 and 10 story points, the velocity for the team would be the average of these values; that is, 20 story points. The calculation would be the same regardless of the unit of measure.  

Typical Assumptions

  1. Velocity counts work only when it is completed.  
  2. There is no partial credit.
  3. Whether or not work is complete is governed by the team’s definition of done. Done generally means that the work item is potentially shippable.

Cycle Time:

Cycle time is the average amount of time a team needs from the moment they pull a piece of work until it is ready to be implemented.  The metric is calculated using the following formula

Average Cycle Time = Sum(UoW Complete Date – UoW Start Date)/ (Total Completed Number of UoW)

UoW = Unit of Work

If a team completes four UoW in a sprint with the cycle times of 4 days, 10 days, 5 days, and 1 day the average cycle time would be 5 days (20 days/ 4 UoW).

The unit of work can be any unit of work the team tracks.  The orthodox view is that all units should of similar types.  We will return to this argument later in this theme. However I do not assume that all units of work are of similar types.  

Typical cycle time assumptions for each of the units of work:

  1. All items are of the same type (story, feature, defect, etc) – we will ignore this assumption for the time being.
  2. The start is measured when work begins on a UoW.
  3. The end (UoW complete) is measured when the UoW is shippable/implementable.
  4. No partial credit.
  5. Start and end do not have to occur in the same sprint

As noted in our re-read of  Daniel S. Vacanti’s Actionable Agile Metrics for Predictability (Chapter 5), cycle time can be approximated using a Cumulative Flow Diagram.  The approximation uses the number of UoW that start and complete for a given period.  

The most significant difference between the two metrics is that velocity reflects how much gets done while cycle time reflects how long.  However, confusion typically arises not around the definitions, but rather around whether they generate the same information.  When all UoW start and end in a single sprint, velocity and cycle time can provide the same information (the approximate version also works in this scenario).  However, it is rare that all UoW start and end in the same sprint. Instead, some inits of work are typically started and completed in a staggered fashion across a number of sprints. Therefore the two metrics typically provide very different information.