In the previous post, we discussed why you would want to measure your performance in Personal Kanban. Today I’ll begin with the most powerful - but perhaps most intimidating - technique. In upcoming posts we’ll look as some less intense methods, so don’t let this post scare you.

In kanban for software design, a "cumulative flow diagram" is used to track performance. A big part of the cumulative flow diagram is its ability to visualize how close you are to completion of a large project, and where bottlenecks or waste appears in the process. It’s a very powerful and descriptive tool.

Above is the cumulative flow diagram for the Modus Cooperandi Personal Kanban. The diagram illustrates how many tasks we have in a given part of our workflow. This is our workflow, so you don’t need to emulate it. The components are as follows:

Backlog: Items that have yet to make it into the workflow.

Priority 3: Items that are coming up in importance.

Priority 2: Items that are important.

Priority 1: Items that need to be done soon.

Working: Items in the process of being done.

The Pen: Items that are waiting for external input.

Complete: Items we’ve done today.

Archive: Items we’ve completed in the past.

On this particular day, we completed 96 things in the past, accomplished 2 that day, sequestered 3 in the pen, and so forth. Of course, as time goes on, your archive is going to become bigger and bigger. In a directed project with a finite number of tasks, this is a very important part of the diagram. For personal kanban however, where tasks will build up forever, it shows us how much we’ve done or are capable of doing.

Simply from a flow perspective though, we might want to eliminate that part of the diagram.

So here, with no archive, we can discern some interesting patterns.

First, we see where we complete some serious work. We also notice where we gain a lot more work. So on days where there is a tremendous dip in the number of tasks, in the above chart (but no dip in the first), we know that we moved a tremendous amount to the archive.

We can also see where we build up backlog again. So, essentially what we have here are two graphs that show us (1) we are completing work and the number of tasks completed is continuing a fairly uniform rise, and (2) we see the actual variations in our work and when we take work on.

Since the chart is a time slice taken daily at midnight, the parts of the kanban with a WIP limit should be uniform, and represented by fairly flat bands, with the only variation coming from “The Pen,” “working,” and “done.” If we have work in the backlog, we should be maintaining a fairly even amount of work in the queue. The diagram illustrates that we've been working to achieve this, and as we’ve worked more closely, the uniformity is starting to manifest itself.

What we want to avoid is having the backlog band grow at an alarming rate. We want work there to feed the queue, but if it gets too overwhelming, we then know we have to start saying no to tasks.

The time it takes to move a task from backlog to completion is called “lead time.” The time it takes to complete a task when you start working on it is called “cycle time.” “Work time" is how long tasks were on your board, and active. “Wait time” is how long a task sits idle in a queue, while waiting to be moved. In a personal kanban, you might move one or even dozens of tasks across your board in a single day, so for you these are the numbers to watch for variation.

If at some point you notice your lead time jumps to 20 days, it’s obvious that you have too much backlog. If your cycle time jumps, something is stopping you from starting work. If your work time jumps, something is stopping you from completing work. If your wait time jumps, something might be stopping you from working at all.

So...how do you measure this? At the end of each day, you can track the information in the cumulative flow diagram by counting the cards in each part of the work flow, and entering them into a spreadsheet. For the “times” you can write start and end dates on the cards, and calculate from there.

Or you can use Agile Zen - which is where these images came from - and leave the tracking up to Nate.