Relationship of Cycle Time and Velocity
I sometimes see clashes between Kanban proponents and their Scrum counterparts. Despite the disagreements, both of these approaches tend toward the same goals and use many similar techniques. Karl Scotland and I did some root cause analysis of practices a few years back and came to the conclusion that there were a lot of similarities between Kanban and Scrum [as the poster-child of iterative agile] when viewed through that lens. I also noticed that while Scrum explicitly focuses on iterations as a control mechanism, Scrum teams tend get into trouble when they ignore Work In Progress (WIP). Conversely, while Kanban explicitly focuses on WIP, Kanban teams tend to get into trouble when they ignore Cadence.
A twitter conversation I was in revolved around Cycle Time and Velocity. Since this is a topic that’s come up before, I thought it would be valuable to describe it more fully. Again, I find there to be more similarities than differences between Kanban (which uses Cycle Time) and Scrum (which uses Velocity) in terms of predicting when a given amount of work will be done, or how much work will be done by a given time.
Cycle Time is the amount of time it takes for a single unit of work to progress from one identified point in the value stream to another. Since the term originated in manufacturing, it assumes that the units of work are essentially identical, and the variability of cycle time is low. The concept also assumes that one can relatively easily produce multiple units in parallel, increasing production capacity and reducing the average cycle time by a factor equal to the number of parallel streams (assuming they are all equally efficient). These assumptions can work with knowledge work like software development, but we do need to be careful that we’re not violating them.
Velocity is the amount of work that can be accomplished in a given unit of time. Velocity is often expressed in “story points” which take the perceived difficulty of a story into account. This generally adds noise to the data, so you’ll likely find it easier to work with a count of stories, instead. Even better, we can split our User Stories until they are of roughly equal size, and call them all “one point” stories. Even if you’re using story estimates for your tracking, then you can easily record the story count, too. If we use multiple teams to produce multiple units in parallel, then the velocities (in story count) may be added to give the overall capacity. (I recommend against adding story points from multiple teams.)
Given that Cycle Time is Time per Work, and Velocity is Work per Time, by adjusting for units we see that these are reciprocals of each other. They are related in the same way that wavelength and frequency are in physics.
If our average cycle time is 2.5 days per story, then the velocity for a two week cadence (10 working days) is 4. Similarly, if a team produces 15 stories in 10 working days, then the cycle time is 2/3 of a day.
For most decision making, people use average cycle time rather than the cycle time of individual units of work. Velocity will always average over the length of a sprint, at minimum. You can, of course, measure cycle times of individual stories. This will enable calculating or eyeballing the variability.
I was asked why I would want to make such a conversion. I can think of four reasons off the top of my head.
1. To look at a situation from a different perspective to gain insights.
2. To understand someone speaking from a different context.
3. To work with organizations where they are, rather than expecting them to conform to my preferences.
4. To reason using the data that’s available, rather than waiting to collect different data.
I don’t mind which framework people use, but I care that that they get the benefits of using it. Sometimes this requires borrowing concepts from another framework to understand what you’re seeing or make a needed adjustment.