Experimenting with Kanban: the cycle time metric

If there is a Kanban practice that keeps surprising me again and again is the cycle time metric measurement and optimization. We defined cycle time as the average time that a story takes from our first state (backlog) to our last state (production). It tells us how much time our team takes to finish a story, on average.

Compared with the velocity metric that most Scrum teams uses, cycle time proved to be more accurate for planning and simpler to comprehend. It is more accurate because it is something that we are measuring and not something that we are guessing. And it is simpler to comprehend because its measurement unit is time and not points. While time is something that we have been dealing with since we were born, points are an artificial unit created to simplify software estimation, which is a very complex task by itself. So, instead of guessing how many points each story costs and then taking as much as the team guesses it can handle in a sprint, we know that the team finishes one story every X days, on average, and that N stories will take them (N * X) days to finish, on average. Much simpler!

My first surprise was when I saw the number of stories one team was refusing after we started to measure cycle time. When I asked them why they were refusing those stories they told me that they were refusing them because those stories were missing some important pre-requisites. Those pre-requisites included: other team’s components readiness in our integration environment, infra-structure, definitions etc. Without those pre-requisites they were likely to come to a halt during development, what would affect their cycle time directly! WOW! Very nice! For the first time, the team became aware of the importance of their definition of ready! And they were fighting for it, now! Amazing!!

Another great surprise was how the team became concerned with their cycle time to the point that they decided to print their cycle time evolution graph and put it on the wall, above their kanban board, so that they could always track it and discuss actions to improve it during their daily checkpoints. This behavior answered a concern that I had since the beginning of our kanban implementation: couldn’t the team become slower without the sprint’s timeboxes? And today I can tell you for sure: NO! The answer is: cycle time. 😉

Advertisements

12 Responses to “Experimenting with Kanban: the cycle time metric”

  1. Kurt Häusler Says:

    “Compared with the velocity metric that most Scrum teams uses, cycle time proved to be more accurate for planning and simpler to comprehend.”

    Apples and oranges. Most Kanban teams track velocity too, they just call it throughput. I wouldn’t say one is more accurate or more useful than the other. A Kanban practitioner needs both to base their decisions on.

    Throughput kind of says more about the capacity of a team. Cycle time says more about how long items stay in queues etc.

    They are related along with WIP. Check out Little’s Law: Cycle Time = WIP / Throughput.

    Also an organization that cares more about how much can be developed in a certain time, for example when time to market is less important than say total ROI, would focus more on throughput. An org that relies on fast time to market would focus more on cycle time.

    • tiagomjorge Says:

      Very good point!! I agree with you that we need both cycle time and throughput to make good decisions. My point is that metrics that we measure (i. e. throughput and cycle time) are better than metrics that we guess (i. e. story points). The way that most Scrum teams measure their velocity is by taking the average of their story points per sprint: an average of a guess. On the other hand, throughput and cycle time are based on measurements only, what is less error prone. Don’t you think?

  2. Dread Pirate Crom Says:

    Great Article but do we think measuring and adjusting behaviour to story cycle time is damaging the team’s ability and willingness to work on bigger or riskier but potentially much more important or valuable things?

    I spent a number of years in a company that measured on time delivery and cycle time.

    Focusing on these metrics without the balance of many other areas can distort behaviour in positive ways in the short term but often in very negative, hard to undo ways in the medium to long term.

    Individuals, teams and managers become myopic and emotionally attached to these numbers very quickly so be careful.

    – So now you’re measuring cycle time, do you plan to *stop* measuring it any time? 🙂

    • tiagomjorge Says:

      Very good point! I totally agree with you! I’ll write exactly about this in a new post soon!

      And yeah, we should stop measuring cycle time once the team is tuned. 😉

    • Trevor Says:

      There’s a simple solution to this challenge: divide cycle time by complexity. This does reintroduce some guess work, but I think it is much easier to determine complexity then the exact amount of time a task will take.

      I like to have a three tiered system for the complexity of tasks:

      Level 1 tasks: I could write out the pseudo-code for this task right now
      Level 2 tasks: I could outline the basic algorithm for this task right now
      Level 3 tasks: I would have to do some research or experimentation before starting this task

      So you then have an average cycle time, which you could additionally break down into level 1 cycle time, level 2 cycle time, etc.

      This has the added benefit of offering more accurate estimates for future work. For example, you could easily categorize your backlog into one of these three levels and be able to determine approximately how long the top priority item would take to get to completion. You could also use throughput for each complexity level to forecast project completion. This method of forecasting is the most accurate I have seen to date.

  3. Focusing on product advancement instead of the development team performance « Tiago Motta Jorge's Professional Blog Says:

    […] Tiago Motta Jorge's Professional Blog Agile Inquirer: questionings and discoverings about agile software development « Experimenting with Kanban: the cycle time metric […]

  4. Gaynelle Hacker Says:

    Just desire to say your article is as astounding. The clarity in your post is just cool and i can assume you’re an expert on this subject. Well with your permission let me to grab your feed to keep updated with forthcoming post. Thanks a million and please keep up the gratifying work.

    • tiagomjorge Says:

      Thank you, very much! Feel free to follow my blog’s feed! And also please feel free to leave new comments, too. 😉

  5. Sid Says:

    A good read. A nit pick though… instead of stating your definition of cycle time, consider using the term “lead time”. This appears to be the correct term in this situation.

    There are a few links I could provide, but this one has some drawings which clarify the point.

    http://stefanroock.wordpress.com/2010/03/02/kanban-definition-of-lead-time-and-cycle-time/

  6. Hassan Says:

    “we know that the team finishes one story every X days, on average, and that N stories will take them (N * X) days to finish, on average.”

    I think you’re actually making your predictions with throughput, not cycle time. In the example above, you might say the team finishes 1 story every day, or 5 stories per week.

    You’d have to predict using cycle time differently. Let’s say your cycle time is 10 days and you have 40 stories. (Cycle Time * Stories) here would be 400 days to finish. This would be true if you only had one story in progress at a time, but most teams will have multiple in progress at once. How would you account for that?

    • tiagomjorge Says:

      Hi, Hassan! Thx for your comment!

      You are right: we need both the cycle time AND throughput to make a prediction. The relation between those variables can be defined by this formula:

      throughput = (wip / cycle time)

      In my example, “the team finishes one story every X days”, the throughput is “one” and the cycle time is “X”, so my prediction works with the (N * X) calculation of remaining days to finish the work, with N being the number of stories to do. In your example, with a cycle time of 10 days and 40 stories, we would still need the throughput to make a correct estimation of remaining days. The formula would be something like (40/throughput) * X. In my example, as the throughput was 1, I didn’t have to divide N by it.

      Best regards!
      Tiago.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: