The Kanban Pocket Guide: Chapter 6 - The Basic Metrics of Flow

The four flow measures to track in Kanban are:

WIP: The number of work items started but not finished.
Cycle Time: The amount of elapsed time between when a work item started and when a work item finished.
Work Item Age: The amount of elapsed time between when a work item started and the current time.
Throughput: The number of work items finished per unit of time. Note the measurement of throughput is the exact count of work items.

In Chapter 4, we talked about how important it is to have a well defined point at which work is started and a well defined point at which work is finished. For our purposes here, the reason for this importance is that all basic metrics of flow are defined in terms of those started and finished points. For a fuller discussion of this concept, I'll point you to Chapter 4. Just know that for the rest of this chapter we will assume you have a process with well-defined boundaries.

In and of themselves, the above metrics are meaningless unless they can inform one or more of the three Kanban practices. Further, these four flow measures represent only the minimum required for the operation of a Kanban system. Teams and organizations may and often should use additional context-specific measures that assist in making data-informed decisions^1^.

Work In Progress

WIP: All discrete units of potential customer value that have entered a given process but have not exited.

To calculate WIP you simply count the discrete number of work items within your process boundaries as defined above. That’s it: just count.
Your natural objection might be, “doesn’t that mean you have to make all of your work items the same size?” After all, the work items that come through your process are of different durations, are of disparate complexities, and may require a wide mix of resources to work on them. How can you possibly account for all of that variability and come up with a predictable system by just counting work items? While that is a reasonable question, it is not something to get hung up on.

As we saw in Chapters 2 and 3, when it comes to WIP, there is no requirement that all of your work items be of the same size. There is not going to be a need for any further complexity to be added to the WIP calculation such as estimating in Story Points or assigning ideal hours to each work item. This concept is probably very uncomfortable to those of you who are used to thinking about work in terms of relative complexity or level of effort, but there is no requirement to do any kind of upfront estimation when practicing flow.

Nor is there any restriction on the level at which you track work item WIP. You can track WIP at the portfolio, project, team, individual level—just to name a few. All of these types of decisions will be completely up to you and should be made given the constraints of your context.

It should also be noted that there is a difference between WIP and WIP limits. You cannot calculate WIP simply by adding up all the WIP limits on your board. It should work that way, but in reality it does not. This result should be obvious as most Kanban boards do not always have columns or boards that are at their full WIP limit. A more common situation is to have a Kanban board with WIP limit violations in multiple columns--or across the whole board. In either of those cases simply adding up WIP limits will not give you an accurate WIP calculation. The sad truth is there is no getting around actually counting up the physical number of items in progress to come up with your total WIP.

Bottom line, if you want to use Kanban but are not currently tracking WIP, then you are going to want to start. Sooner is better than later.

Cycle Time

In the previous section I stated that a process has specific arrival and departure boundaries and that any item of customer value between those two boundaries can reasonably be counted as WIP. Once your team determines the points of delineation that define Work In Progress, the definition of Cycle Time becomes very easy:

Cycle Time: The amount of elapsed time that a work item spends as Work In Progress.

This definition is based on one offered by Hopp and Spearman in their Factory Physics book and, I believe, holds up well in most knowledge work contexts. Defining Cycle Time in terms of WIP removes much—if not all—of the arbitrariness of some of the other explanations of Cycle Time that you may have seen (and been confused by) and gives us a tighter definition to start measuring this metric. The moral of this story is: you essentially have control over when something is counted as Work In Progress in your process. Take some time to define those policies around what it means for an item to be “Work In Progress” in your system and start and stop your Cycle Time clock accordingly.

You will also not want to overlook the emphasis on “elapsed time”. The use of elapsed time is probably very different from the guidance you have previously been given. Most other methodologies ask you to measure only the actual amount of time spent actively working on a given item (if they ask you to measure time at all). I happen to think this guidance is wrong. I have a couple of reasons why.

First, and most importantly, your customers probably think about the world in terms of elapsed time. For example, let’s say that on March 1, you communicate to your customers that something will be done in 30 days. My guess would be that your customer’s expectation would be that they would get their item on or before March 31. However, if you meant 30 “business days” then your expectation is the customer would get something sometime around the middle of April. I am sure you can see where that difference in expectations might be a problem.

Second, if you only measure active time, you are ignoring a large part of your flow problem. It is the time that an item spends waiting or delayed (i.e., not actively being worked) that is usually where most of your unpredictability lies. It is precisely that area that we are going to look at for most substantial predictability improvements. Remember, delay is the enemy of flow!

There is still a more important reason to understand Cycle Time. Cycle Time represents the amount of time it takes to get customer feedback. Customer feedback is of vital importance in our knowledge work world. Value itself is ultimately determined by the customer, which means your team is going to want to make sure it gets that value feedback as quickly as possible. The last thing you want is to develop something that the customer does not need—especially if it takes you forever to do so. Shortening Cycle Time will shorten the customer feedback loop. And to shorten Cycle Time, you are going to first need to measure it.

Work Item Age

Age is by far the most important of all the flow metrics to track. The reason why is covered in great detail in Chapter 1 of this book (which may be why you started reading this chapter in the first place).

The definition of WIP Age is:
Work Item Age: the total amount of time that has elapsed since an item entered a workflow.

Because Work Item Age is a measure of current time in progress for all of your current work in progress it, by definition, only applies to items that have entered but not exited the workflow. Once an item exits the workflow, then all the age that has accumulated up to that point immediately becomes converted to Cycle Time.

Throughput
I have saved the easiest metric to define for last. Simply put, Throughput is defined as:

Throughput: the amount of WIP (number of work items) completed per unit of time.

Stated a slightly different way, Throughput is a measure of how fast items depart a process. The unit of time that your team chooses for your Throughput measurement is completely up to you. Your team can choose to measure the number of items that it gets done per day, per week, per iteration, etc. For example, you might state the Throughput of your system as “three stories per day” (for a given day) or “five features per month” (for a given month).

A further thing to know about Throughput is that many agile coaches and consultants use the words “Velocity” and “Throughput” interchangeably. While Velocity can be defined in terms that are the same as Throughput, most of the time when a coach says "Velocity" he or she means "story points per sprint". When defined in terms of story points, you should know that Throughput and Velocity are anything but synonymous.

If Throughput is how fast items depart from a process, then Arrival Rate is how fast items arrive to a process. I mention this fact here because depending on your perspective, Arrival Rate can be thought of as an analog to Throughput. For example, let’s say that the “Development” step and “Test” step are adjacent in your workflow. Then the Throughput from the “Development” step could also be thought of as the Arrival Rate to the “Test” step.

Even more importantly, though, comparing the Arrival Rate of one step in your process to the Throughput in another, different step, may give you some much needed insight into predictability problems. I will be going into much more detail about this comparison in the coming chapters. However, my more immediate reason in discussing Arrival Rate is simply to point out that how fast things arrive to your process could be just as important as how fast things depart.

The Throughput metric answers the very important question of “How many features am I going to get in the next release?” At some point you are going to need to answer that question, so track Throughput and be prepared.

Conclusion
What I have shown here are just the basic metrics of flow to get you started: WIP, Cycle Time, WIP Age, and Throughput. There are most certainly other metrics that you will want to track in your own environment, but these represent the metrics common to all flow implementations. If your goals are improvement and predictability, then these are the metrics that you are going to want to track.

Endnotes
1. John Coleman and Daniel Vacanti, "The Kanban Guide" https://kanbanguides.org/

Remember you can always download a PDF of The Kanban Pocket Guide here: https://prokanban.org/kpg/