Essential Kanban Metrics

While most of the Agile transformations I've guided were into Scrum, there have been some Kanban teams along the way. If done poorly, Kanban is merely understood as a task list on a board shared by a team. That really isn't the way it's supposed to be. Today I'm going to outline briefly the metrics to look for in Kanban, which should provide the insight needed to do a proper transition to Kanban. While I'm making the assumption here that the reader already has an idea of what Kanban is, here's a succinct description provided by Atlassian:

Kanban is a popular framework used to implement agile software development. It requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.

The first metric to look for in Kanban is cycle time. With cycle time you are measuring how long a task remains in process before completion. If you use Jira there's an option to indicate the time spent visually on each story card in the board. Note that this is different from lead time, in that cycle time only begins when the team starts working on the task. If cycle time is high, that means that the work is slowed somewhere, while low cycle time indicates that everything is moving along efficiently for the task. A cycle time histogram would be used to measure and predict delivery.
via Nave
The next metric to consider in Kanban is throughput. This metric looks not at the time taken with individual tasks, but rather the total work completed in a specific period of time. Only work that is delivered is counted with throughput, and not anything that is still in progress. The average of a few weeks completion can be averaged to find the team's capacity. So, for instance, if they complete in successive weeks 4, 5, 7, and 5 tasks, we'll gather that their capacity is roughly 5 tasks per week. Tracking a teams performance with throughput is done with a throughput histogram. 
via Kanbanize
A third component to have in play is a Work in Progress (WIP) limit. This isn't really a metric, per se, but by limiting the amount of work the team can do at a time the overall efficiency should approve. A rule of thumb is that the WIP limit should be the same number as people on the team, meaning one task per person at a time. In my opinion this is rather unrealistic, as it is often the case with some teams that dependencies and blockers beyond the team member's control creates a wait time. They shouldn't be twiddling their thumbs and playing solitaire while they wait. In reality, the WIP limit needs to be based on the team's knowledge of their workflow, and established in collaboration with them. It also must be enforced in order to have any meaning.

The element I've found particularly useful with Kanban teams is the cumulative flow diagram. This diagram shows the distribution of tasks in various states accumulating over time. A quick look is all it takes to understand how things have been going. If the gradient of work in progress is growing, you likely have a bottleneck. If, on the other hand, you see 'done' work piling up the most then things are moving along efficiently. 
A bottleneck indicates that the team does not have capacity to handle the flow of work. This could be due to absences, an increase in total work coming in, or some other factor. What you must to is look carefully into the issue and ascertain what is causing this problem. Perhaps more team members are needed, if the increased work isn't going to slow down, or else an adjustment to the WIP limit is called for. Whatever you do, do it quickly in order to set the team on the right path again. Little is as bad for a Kanban team's morale as feeling that they are underperforming, whether or not it is within their direct control.

Hopefully some of this has been useful. There are certainly abundant resources available on the internet to bring you up to speed, and at the very least this post can serve as a starting point for you.