Kanban is a work management method that took its shape from the Toyota Production System (TPS) developed in Japan in the 1940s. It is characterized as being a pull system, which responds to current customer demand instead of generating products on an ongoing basis that can become waste. At a lower level, pulling is about starting new tasks only if there is capacity to do so, without overloading the system.
The Kanban Method has a series of principles and practices, one of which is workflow optimization. Optimizing workflow is essential to achieving and maintaining a stable and efficient work rhythm. Kanban utilizes several metrics to help analyze processes and provide the objective data needed to determine what can be improved.
Before presenting these metrics, let’s first take a look at workflows. A workflow is a set of stages, phases, or moments each work activity goes through. In other words, it is the life cycle of our tasks, starting from when the need is identified through to its delivery.
When determining your workflow, it is important to have a shared understanding about two key elements:
- The phases or stages that make up your team’s workflow
- What must happen for a task to enter and exit a phase or stage
You would be surprised how many different answers you’ll get when asking your team members, “When do you consider a task to be finished?” and “Does finishing mean delivering?”, especially if you regularly collaborate with other teams or areas during product development.
If you manage to define an adequate and clear workflow, remember to never assume that it is stable. The product you are developing, your team, and the context in which you work will change. You may need to modify your workflow to improve new processes and remain efficient.
Once you have analyzed and defined the workflow that best suits your context, start applying these Kanban metrics to make your processes and practices more efficient.
TIP! Several of these Kanban metrics can be easily calculated by downloading and using our Time and Motion Template.
Lead Time allows us to know how long it takes to respond to a need. It measures the time elapsed from when a need is identified (enters our workflow) to when it is delivered (leaves the workflow). That is, it measures the life cycle of a work activity.
In more concrete terms, the Lead Time of a PBI (Product Backlog Item) measures the time elapsed from when it is added to the Product Backlog, passes through the intermediate stages, and is set to DONE.
This means passing through all the intermediate states that our particular workflow has: prioritization, development, quality testing, etc.
Lead Time is longer than the time it takes to develop a task (this time is measured by Cycle Time, which we will see below). Lead Time can be understood from the user’s point of view as the time they wait starting from when they make a request until they receive the completed work item.
Cycle Time is similar to Lead Time, except that the measurement time starts as soon as the task begins to be developed. In other words, the Cycle Time measures the time elapsed from when a PBI enters IN PROGRESS until it is set to DONE.
How is it different from Lead Time? While Cycle Time doesn’t provide information about how long a user has to wait, it does measure how efficient the development team is in carrying out the development of an item and delivering it.
An example: considering the time that an item spends in the Backlog, a PBI could have a very high Lead Time and a very short Cycle Time. The difference could be the time it took the Product Owner to prioritize the PBI to the top of the backlog list.
The WIP, or Work In Progress, does not measure a period of time, but is an indicator of how many items are being developed at a specific time. That is, the amount of PBIs that are in IN PROGRESS at any given time.
But what do we mean by IN PROGRESS? This isn’t always as obvious as it may seem. The three natural stages of any action are To Do, In Progress (Being Done), and Done. There aren’t more; it is logically impossible. However, most workflows will need to break these stages down into smaller activities or phases to more easily visualize and manage a process.
When we look at these new phases, we see that they fit into one of the three natural states. If you want to include a QA phase to show what items needed to be tested, add it to In Progress since it not part of the “about to start” or “finished” phases. On the other hand, having two phases in TO DO like those in the image above allows us to differentiate between the PBIs that are in the Backlog and those that are prioritized and ready for development. This is what I was referring to earlier when discussing optimizing our workflow.
Going back to WIP: if I have multiple phases of progress, what needs to be measured? When we remember that the objective of this metric is to know the amount of PBIs that we have in progress, we must measure the total IN PROGRESS status. However, measuring each of the internal phases will give more visibility into the workflow’s health status. It is common to see few things in “Development” and a lot in “QA”. Measure the WIP of each and you will have information to improve your processes.
If you know the speed of Scrum, this metric will be familiar to you. Throughput measures the amount of work items that someone can complete in a period of time. Throughput does not measure Story Points or User Stories, but the total PBIs that can be delivered in a period of time, regardless of their nature.
And what period of time is that? As working in Kanban has no iterations, the team will decide the period of time. Start by measuring what is delivered over a week or a month. Keep this unit of measure stable, but adapt it in the future if you feel the need to increase or decrease the period of time that is being measured.
Kanban Metrics: Next Steps
If you work in Kanban or any agile framework, metrics are a really useful tool to understand how we work: focusing on finishing tasks instead of starting them, understanding what and where our bottlenecks are, starting and delivering work at a sustainable pace, etc.
Download our template to help track the time it takes to do a manual task. (It can be used for automated processes too, but is less applicable.) This helps with two things: 1. understanding WHERE in a current process you have bottlenecks or activities that are taking too long, and 2. tracking a NEW manual process to see if it’s meeting expectations in the time it takes to do something. It is also useful for seeing where different people perform a process differently.
Metrics provide us with objective and real data. With this data, you can understand how your processes work and, from there, make the most appropriate decisions to optimize them.
I hope this helps,