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. 
via Kanban Tool

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. 

Popular posts from this blog

Changing Jobs Every Two Years

-
In today's job market, it's becoming increasingly important for employees to take control of their careers and maximize their profits. One way to do this is by changing jobs every two years. According to research, staying employed at the same company for over two years on average will make an individual earn less over their lifetime by about 50% or more. This is a conservative estimate assuming that your career will last only ten years, but the longer you work, the greater the difference in earnings over your lifetime. In 2014, the average raise an employee can expect is only 3%. Even the most underperforming employee can expect a 1.3% raise, while the best performers can hope for a 4.5% raise. However, the inflation rate is currently 2.1%, meaning that your raise is actually less than 1%. This can be sobering news, and it's unlikely that management will change their decision. Furthermore, loyal employees are often punished for their dedication, while those who jump ship ar
Read more

Project Management in Action: Enhancing Communities through Projetos Sociais Estação Vida and Uberlandia Development Initiatives

-
Image
Introduction In the bustling city of Uberlandia, Brazil, lies the Shopping Park neighborhood, which has undergone significant changes over the years. Despite its humble beginnings, the community has made great strides in urban development. However, it still faces challenges, particularly regarding social vulnerability and access to essential services. In response to these needs, Projetos Sociais Estacao Vida emerged as a beacon of hope and empowerment for children and young people in the area. Alongside this, the establishment of Uberlandia Development Initiatives (UDI) created an avenue for international support and fundraising. This essay explores the location and significance of the Shopping Park neighborhood, the activities and impact of Projetos Sociais Estacao Vida, my personal involvement with the community center, the establishment and goals of UDI, and the recent achievement of fundraising for security cameras. Additionally, it highlights the connection to project management i
Read more

The Journey to Agile Transformation: A Scrum-Based Approach

-
Image
The concept of Agile transformation, particularly in industries perceived as traditional, such as publishing, often comes with a heavy dose of skepticism. A pivotal moment in my career was steering such a transformation for a publishing company’s engineering team, aiming to adopt Scrum methodologies. The journey, although fraught with challenges, offers valuable insights into driving change even in the most unlikely environments. Overcoming Leadership Hesitancy Initially, the transformation encountered resistance. A new boss, with roots in a different era of publishing, held the belief that Agile frameworks, with their iterative nature and flexible deadlines, were incompatible with the rigorous deadline commitments of our industry. This underscored a common misunderstanding of Agile: it’s not a lack of structure or discipline, but a more responsive and efficient way to manage projects. Despite efforts to clarify this, my explanations met with resistance, leading to a professional parti
Read more