Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

Measuring Kanban Lead & Cycle Time

Now that we are using our Kanban board for a while, it’s time to do some analytics with the visualized information on the whiteboard. Kanban is not only about visualizing your process with a bunch of post-it’s, you can actually do a lot with those “post-it’s”. What I will try to explain in this post is how you can define the lead & cycle time of your items on the board. That way, we can provide some time-related information to our customers about how long it will take to make a particular feature and how long it will take from ‘request’ till ‘delivery’. 

When you use the Scrum methodology to deliver new features to your client, it’s clear that your feature will be ready by the end of a sprint (in normal circumstances). That’s because it uses a time-boxed approach. Using Kanban however, you don’t have any time-boxed iteration. That way it’s quite hard to tell the client when the request will be accomplished.

First of all, what’s the defintion of a lead time and a cycle time? And also, what’s difference anyway?

Lead time

This is the time needed to get your feature ready. In Kanban, this is the time from when your item is added to the backlog till your item is live. So the clock starts when the request is made and ends at delivery.


Cycle time

This is the time needed to ‘make’ a feature or ‘complete’ a task. In Kanban, this is the time when your item is in a ‘in process’ state and there is someone working on that particular item. So the clock starts when work begins on the request and ends when the item is live.


The difference?

The lead time is the time and not the effort spent on the item. You may have a lead time of 20 days, but there were only 2 hours work on the item. The Lead Time and Cycle Time do not have the same unit although. Lead Time is measured by elapsed time (minutes, hours, etc.). Cycle Time is measured by the effort spent on the item defined by time per unit (minutes/task, hours/part).



Now you know the difference between the two, it is obvious that the lead time is more relevant from the business perspective than the cycle time. Actually the cycle time is what the team can influence by changing the work process. Sharper WIP limits for example can reduce the cycle time, but also the determination of the bottleneck in the flow can help you to improve the cycle time.

What I will do now is track 4 things n the Kanban board:
  1. The date as when an item/feature is added to the backlog = the request date
  2. The date as when an item enters the ‘todo’ column
  3. The time each person spends on anthe item
  4. The date as when anitem is ready/live

Using these 4 measurements, I will be able to determine the lead and cycle time of our board.

Note: I’m not quite sure about the time as when the item is ready. Is it really ready when the feature has passed the acceptance phase? Or is it really ready when the feature is ‘live’? Any feedback is really appreciated!

In a next post, I will try to explain how you can improve the lead and cycle time using my personal experiences. Thanks for reading!

How we use Kanban in our development team

A while ago I wrote a blogpost about why scrum didn’t work for us. Some of you did suggest me to use the Kanban methodology instead. This would be a much better suit for our team. I did a lot of research of what Kanban really is, what the best practices are and how to implement this in our team. I will tell you in a few steps how we did this..

First of all, what is Kanban? Well, Kanban is a method to visualize the development work flow and the work in progress. Kanban has 5 principles:

  • Visualize the workflow
  • Limit WIP
  • Manage the flow of work
  • Make process policies explicit
  • Improve collaboration 

Using these aspects, you can highlight any bottlenecks in the development process. You have a visual overview of the things which are happening in your team, so you can guide it. Perhaps change the process, change the WIP limits, ..  

Kanban is an approach to change management. It isn’t a software development or project management lifecycle or process.

A kanban system is often designed on a big white-board used to reflect the workflow. Different color cards are used to show different types of work. This could be a task, a user story, a bug. There is a more detailed description of the task written on each card.

The first thing I had to do is reflect the development cycle to columns on the whiteboard. Pawel Brodzinski made a very interesting blogpost about that. Using his guide, I created my first-ever Kanban bord. This is how our ‘version 1’ board looks like:


Note that the columns seem to reflect some kind of waterfall style process mapping. Well it isn’t. The Kanban board reflects all phases an item must go through in the development cycle. It encourages small independent user stories to be developed in little pieces. The columns on the Kanban board don’t represent hand-offs between team members but more or less the state of what’s the feature in during that time in its development lifecycle.

As you can see, we also use some Kanban queues. Those are a small inventories between two processes to create the appearance of instant availability. 


Some notes on our board

  • How did we define the WIP limits? Trial and error.. There is no science which will tell you what’s the best WIP limit number. It depends on your process, your team capacity, ..
  • We will not continiously deploy. We keep a list of features/bugfixes in the ‘ready’ column, and the PO decides when there is enough ‘buzz’ to make a commercial feature release/bugfix release.
  • High priority is a special ‘swimlane’. If there is an item there, mostly a bug, the developer is obliged to pull that item when he is ready for some new work.
  • There will be a montly retrospective meeting. In this meeting we will discuss the board, check if the colums are still good and if there are other remarks.
  • The queue will (mostly) be fed by our weekly prioritization meeting.


Why is Kanban better than Scrum (for us)

  • First of all, they are both process tools. They both help us to work more effectively.
  • The biggest difference is that Scrum is iterative based and Kanban not. This was a problem for us as with Scrum, we never released what was planned in our sprint.
  • We went from PO driven development to a combination of PO driven and sales/client driven development.
  • We handle critical issues much faster that we used Scrum, where you have to wait till the start of the new sprint.
  • We can prioritize our items so important things go first.
  • Developers have more motivation (maybe because Kanban is less prescriptive?)
  • It’s easier to work on multiple products. If we want, we can even use a different swimlane for each product.


What will change?

  • Other (bigger) post-it’s with more information to visualize. The current post-it’s only have a brief description of the ‘todo’, but I want more information on it. 
  • I also want the start/end date and the time spent on the task visualized. I would like to make some stats to define average lead time (starts when the request is made and ends at delivery) and cycle time (clock starts when work begins on the request and ends when the item is ready for delivery)
  • Investigate the possibility of using swimlanes for user stories and the linked user story tasks.
  • Kanban cards are now colored by type. Like: a feature, a bug, a task, .. Perhaps we can use the colors tho define which type of work. Like: core development, configuration, design, marketing, .. ? (any suggestions on that are welcome!)
  • The outline of the sub-columns needs to be smaller, or maybe dot-lined. Now it’s hard to see the general ‘flow’.


Some interesting links


Thanks for reading and I’ll keep you posted when something changes in our Kanban story!