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.