Agile has some domains that must be equally observed. Thus, for every result of a digital transformation, you must link to business results, and using kanban metrics is a way of measuring it.
All companies have workflows so there is much to learn how to manage them. And many of the metrics in this post are intended to improve flow, without looking at individual people.
In this article, we will focus on the organizational domain to use Kanban Metrics to find better results and get efficient performance from employees.
What are the metrics for Kanban?
1. Lead Time
It is the most agile efficiency metric that exists because, in addition to being easily measured (low investment), it guides us where to look for more results from our work (high return).
Lead Time consists of measuring the time between the moment you commit with the customer to do a certain job until the delivery of the increment of the product or service to the customer.
For each of the items, you or your team commit to work on, record the date the commitment was made. It can be a task registration system, backlog control, or even the date of the email reply (or meeting minutes) where this activity was negotiated.
This point will be your Commitment Point. When you hand in the activity, mark the delivery date. This will be your Delivery Point. Subtracting the commitment point from the delivery point you will have the item’s lead time.
Lead Time = Delivery Point – Commitment Point
Observing the variations between the items can bring many insights on how to improve the daily work. When we start working with lead time, we can guide efforts looking at the added value for the customer, we can discuss routines, and even responsibilities, with more pragmatism.
Even if in your company you understand that your customer is internal, that is, you are committed to some internal demand, we always recommend considering the entire flow. The moment where the company has committed to a real customer to the point where this item was delivered to this customer.
The Throughput consists of seeing how many items an area, team, or person delivers in a period. It’s like watching how many cars pass through a certain intersection, or how many liters of water pass through a pipe.
Define a period: week, fortnight, sprint, month, quarter. And within this period, how many items arrived at the Delivery Point. That’s right, quantity.
One of the reasons it’s important is the perception of completeness. Able to simply see how many work items have been completed. This indicator helps to give a view of achievements and completions.
And a good way to increase this indicator is to work with small items. Working with small items brings a series of advantages such as delivering faster value and better predictability, among others.
It consists of observing how long an item was waiting before starting to work. This is a key indicator to balance with throughput and to measure the time and wait of your backlog items.
Measure the time from the moment the action or task was requested to the moment the team started working on this activity.
Remember that the request may have been formal, using official tools such as demand or project openings. Or informal, such as by email or a phone call.
An agile team is working on items that deliver value. An old item may no longer be relevant to the customer, and perhaps it shouldn’t be done anymore.
A team that is always working with old items may not be updating their backlog and validating new hypotheses, nor may they be learning new things about their product.
4. Occupancy rate
This indicator looks at how the team is working. Going back to the example of water in a pipe, if there is no force in the water in the pipe, there is no flow and the water will stop in parts of the pipe.
However, if we put too much pressure on the pipe, the pipe is bound to burst. This in itself is a point of attention, but in creative work, the high occupation can still lead to paralysis.
Everyone working on several different items causes us to have a lot of coordination costs and context switching costs, decreasing the teams’ productivity.
This indicator consists of the number of items in progress (WIP) in your team divided by the Team Capacity (Limited WIP).
If you’re using a Kanban board, with its flow and its well-defined Capacity limits, it’s easy. It consists of counting how many items are in progress and dividing by their capacity.
Occupancy rate = # items in progress / ΣWIP
Working with a high occupancy rate leads to overload. This, in turn, causes serious problems, including the loss of people from the company. On the other hand, working too low is a waste. It means this team could be delivering more, but they are underutilized.
Incidents consist of frequently tracking things that went wrong in the products or services delivered by this team. If it’s a development team, it could be the number of bugs. For a product/service team, several complaints, and for a support team, several tickets.
The idea of this indicator is to record and track the occurrences of these events. Most companies have one or several tools to track this.
This is an indicator that must be associated with a period so that it can relate the actions of this period and the impacts (which may or may not be immediate).
Teams need to take responsibility for what they produce. When there are two separate teams for design and support, for example, it is common for the design team not to worry so much about quality. After all, he won’t fix the problems he caused.
Return on investment. This is the kind of decision we make empirically daily. Two factors make up this indicator. Return and Investment.
The investment you can measure in cash considering the acquisition of tools and licenses, contracting third-party services, among others. But you also can measure in dedication.
Return can also be measured in different ways. Direct revenue is the most obvious, but we can also look at other things like customer acquisition, churn avoidance (percentage of customers leaving us), or session time.
The idea is to create the following simple relationship:
ROI = return / investment
With this, the team can better choose which items have the highest ROI, the ones that are worth making. For each work, item record the result of dividing return by investment
In addition to the point explained above, the team can observe the ROI accumulated in a period and see if its actions, in this period, are bringing high returns compared to itself in another period.
7. Little’s Law
Kanban Metrics in isolation can provide important information, but it is possible to combine them and go much further. Emerging from John Little’s study of queuing systems, we have Little’s Law to help us with this combination.
Little’s Law is a well-known formula that relates Throughput, Lead Time, and WIP. The idea is that any of these three metrics you can define as long as we have the value of the other two.
This has a few definitions:
Lead Time = WIP / Throughput
Is it worth joining metrics for your company?
There is a plethora of other information you can glean from analyzing a team’s workflow for Kanban Metrics.
However, with this basic information about the behavior of the workflow, it is already possible to define strategies for different situations.
You can define the expected volume of deliverables to complete a project by a certain date, the amount of extra effort required to achieve a certain volume of deliverables, and much more.
These metrics are a great way to put into practice the evolutionary approach of Kanban Metrics, making visible the various deficiencies of the workflow so that they can be solved with the collaboration of everyone.
Team metrics are very important to help make better decisions and true empowerment comes from metrics.
These indicators will help you gain better insights into what to prioritize and where the leverage points might be for really significant improvements in the organization.
GitScrum supports your team to better results and effective deliveries!
Set your workflow and board to guide your Agile team, assign Tasks, Subtasks and keep in charge of the whole process evolvements. Allow your Agile team to collaborate.