Cycle time?

In a recent discussion of Agile metrics, I was asked whether there was a difference between cycle time and throughput.  The simplest answer is that they “feel” similar. Many in software measurement define throughput as the number of units of work (UoW) delivered per unit of time; while cycle time is the amount of time per unit of work (as defined in Actionable Agile Metrics).  The two metrics are the reciprocal of each other. These definitions are functional; however, the cycle time metric is an abridgment of the how the measure is defined in the broader process measurement world.  With the profusion of lean six sigma black belts in the software measurement world lack of precision in the definitions can lead to comical misunderstanding.  Cycle time, with and without lead time, tell interesting but very different stories and are both useful.  Once we get into the weeds, the difference between the two metrics relates to the timeframes the two metrics measure. The precise industry definition of cycle time is the combination of lead time and process time (lean six sigma).  Throughput is both the inverse and measures what is delivered during the processing timeframe with the lead time excluded.

An example to help sort out the nuances in definitions:

Unit of Work Lead Time Processing Time Sprint (5 Days) Story Points
UoW 1 10 days 2 Days 1 3
UoW 2 2 3 1 2
UoW 3 60 5 1 3
UoW 4 3 3 1 5
UoW 5 4 3 2 3
UoW 6 7 7 2 8
UoW 7 1 15 2 13
UoW 8 0 1 3 1
UoW 9 4 3 3 2

Notes (example assumptions):

  1.  In the example all UoW start and complete in a single time period or sprint. 
  2. The team size does not change in any of the time periods.
  3. The data is made up for the example.

Average Throughput:  

Sprint 14 Units 5 days4/5 = .8 per day

Sprint 23 Units5 Days3/5 = .6 per day

Sprint 32 Units5 days2/5 = .4 per day

Average Throughput9/15=  .6 UoW per day

(Remember do not average averages)

Throughput can be used as a planning metric and is a reflection of efficiency.

Average Cycle Time w/o Lead Time:

Sprint 113 days4 Units13/4 = 3.3 days per UoW

Sprint 225 days 3 Units 25/3 = 8.3

Sprint 34 days2 Units  4/2 = 2

Average Throughput42/9=  4.7 UoW per day

Cycle time is often used as a planning metric and as a reflection of efficiency.

Average Cycle Time w/ Lead Time:

Sprint 188 days4 Units44/4 = 22 days per UoW

Sprint 237 days 3 Units 37/3 = 12.3

Sprint 38 days2 Units  8/2 = 4

Average Throughput133/9=  14.8 UoW per day

The higher average cycle time, the more apt customers are going to feel underserved. The average cycle time trending upward over time is often an indication of demand outstripping capacity.

In general, all three of these metrics provide interesting information and can be used to identify areas for improvement.  Average throughput in an iteration/sprint-based implementation tends to be less due to the fixed nature of the cycle. Therefore it is a useful planning tool for the team even if they are using velocity.  Throughput can provide a method to validate or challenge the amount of work is pulling. Software teams tend to being optimistic and bite off more than they can chew. Average cycle time w/o lead time helps to answer the question when will a piece of work be completed and is a proxy for cost.  Note, when this metric is highly variable its predictive value is weakened. Finally, the other cycle time (average cycle time with lead time) helps reflect on the relationship between demand and capacity.   

Throughput and cycle time seem similar.   Throughput and both versions of cycle time are useful for highlighting different issues. As with any measure, the question as to whether they are valuable at any specific time depends on the question you need to answer!