Metrics are engrained in kanban. They play a role in several kanban practices like visualizing and managing flow, and support the agenda’s for sustainability, service orientation and survivability.
At the Lean Kanban Central Europe 2014 Conference Wolfgang Wiedenroth talked about the power of metrics. In his presentation he provided many examples of using metrics with kanban.
When you visualize the work using cumulative flow diagrams, metrics become visible. For instance you can measure the arrival rate and the departure rate. You can measure your throughput and use that to create insight into the time it takes to release software.
Kanban promotes to do visualization, and metrics help to do that. Visualized metrics let you see things faster. They help to identify patterns and to give everybody the same picture to build a shared understanding. As Wolfgang stated: “visualized metrics are great feedback loops”.
Metrics in kanban can help you to manage flow to balance demand and capability. A Weibull distribution can be used to predict the flow after you have gathered some data. You can calculate the shape parameters using the available data to have a graph that you can use to set service level expectations about which percentage of the features can be delivered at a certain date or the range of time typically needed to solve bugs.
By using Little’s law you calculate the project lead time and budget. These calculation would only work for the second leg of the project as they don’t project take start up and finishing effects into account. Wolfgang concluded that “metrics help you forecast your project without estimating”.
In kanban survivability talks about about the purpose of the services that are provided and the criteria which need to be fulfilled for the service to fit the purpose. According to David Anderson fitness criteria are customer value metrics which they use to select a service, like delivery time, quality or predictability. You want to measure and track some key measurements.
Wolfgang suggests to ask your customers what they care about. In his blog post evolving scrum with kanban #2 – measure what? he gives an example of a measurement that his team is using to satisfy the needs of the product owner:
In my case, the Product Owner of the team was interested in getting the User Stories that she gave the team to work on, back as soon as possible. She had no interest in how fast tasks would be finished. All she wanted to know was, how long does she have to wait to get a User Story, she asked the team to finish, to be released. This was valuable to her.For my particular situation, a Scrum team using the Kanban Method on Flight Level 2[3] to improve their service delivery, this was the answer to all my questions.
What should I measure, User Stories or tasks? User Stories!
Where should I start to measure? From the point in time the User Story was put onto the board by the Product Owner, the replenishment, to the point the story was ready to be released!
Metrics can be used to support change. They can help to distinct between good and bad changes from an objective point of view said Wolfgang. Some examples are the amount of rework, number of blockers, employee satisfaction and WIP limit breaches.
Wolfgang stated that for metrics to work you need to keep it simple. Chose simple metrics and start measuring and discussing them. You have to regularly check your metrics whether they have become chindōgu: unuseless since they are not helping you in any way.