A New Copy!

Today we tackle Chapter 8 of  Daniel S. Vacanti’s Actionable  Actionable Agile Metrics for Predictability: An Introduction (buy a copy today).  The chapter is titled, “Conservation of Flow Part II.”  In this chapter, we dive even deeper into the conversation of flow and why the assumption that work that enters a process completes and exits is important. (more…)

Getting the most value out of a process is important to any leader.  Balancing getting the most value with getting value sooner complicates the discussion.  In some cases, getting some value sooner is worth more than the same value delivered later.  Guiding the delivery of value is more complicated than a rank ordering a list of user stories and then magically hoping that everything will happen in the most effective and efficient manner possible.  Measurement is an important tool to help team and organizations ask the right questions.  To borrow an idea from Daniel Vacanti’s Actionable Agile Metrics for Predictability, measurement helps people ask the right questions sooner.  The following 6 flow metrics provide process transparency into organizations that leverage continuous flow, scrumban, and/or Scrum as the basis for their Agile implementations.  (more…)



Kanban is a methodology for shaping and controlling the flow of work through a process. Kanban as a method was popularized and honed though its application in lean manufacturing, specifically in the Toyota Production System. The manufacturing pedigree of Kanban led to application of lean and other engineering concepts such as queuing theory. Little’s Law is a mathematical observation that the number of customers in a system equals the average arrival rate multiplied by the average time the customer is “in” the system. Knowing the average time a customer is in process can be used to judge how many resources should be applied or whether changes speed the process up. Lean and Kanban adherents shift the focus from arrival rate to output, which is more interesting in development and manufacturing environments. Many Kanban implementations use Little’s Law to help forecast and measure throughput.

Little’s Law is typically stated in lean/Kanban circles as:

Cycle Time = Work-in-process/Throughput

Work-in-process (WIP) is the amount of units of work between the start and end points of the process. WIP is measured using the same unit of measure that you used to measure throughput. Use story points for velocity, function points for productivity and stories for #NoEstimates.

Throughput is the average output of the process. Examples of development throughput are velocity (average story points delivered per sprint), productivity (function points per person month) or simply as the average number of stories completed in a sprint (this could be explored by the adherents of #NoEstimates).

Here is an example calculation based on a Kanban implementation I reviewed:

  • Current WIP: 175 story points
  • Throughput: 47 story points per period (two weeks)
  • Cycle time: 175/47 = 3.7 periods or 37.2 days (10 working days per period)

Cycle time, based on Little’s Law, is useful for release planning, monitoring flow and judging whether process improvements are effective in reducing cycle time. Having a measure that informs an organization how fast work transits a specific process can be used to plan when an item from the backlog will enter the process (an item is pulled into a Kanban process when there is capacity to begin work) and when it will be complete. This type of information is critical for informed release planning. If we apply the cycle time metric to monitoring cycle time improvements, it should provide the organization with a means of monitoring and measuring whether throughput is improving.

Little’s Law as typically applied by practitioners of lean and Kanban effectively provides a process throughput metric by measuring cycle time. The original application of Little’s Law focused on waiting time in the queue (how long items sat in the backlog). The current interpretation of Little’s Law is more useful for development organizations trying to maximize output rather than minimizing the backlog wait time.