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.
- To look at a situation from a different perspective to gain insights.
- To understand someone speaking from a different context.
- To work with organizations where they are, rather than expecting them to conform to my preferences.
- 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.
Thanks for posting this.
I would say that Cycle Time doesn’t assume the units of work are of identical size. The point of tracking CT isn’t to worry about individual work items, but rather to look at the organization’s performance in the aggregate. Mean CT and CT variation are interesting; the length of time it took Team A to complete Work Item B isn’t particularly useful. The change in CT variation over time can be an indicator of improvement.
After our earlier conversation, I added the following to the metrics book (in progress): “Lean metrics can’t be compared with Agile metrics easily or reliably. It’s arguable that Velocity and Cycle Time are mathematical reciprocals – Velocity is the quantity of work completed per unit of time, and Cycle Time is the time required to complete a unit of work. Yet, this superficial relationship ignores details of how the different teams use the measurements. Thus, it’s problematic to convert between Agile and Lean metrics.”
Here’s an example of the difference in context. Consider a team using Scrum with 2-week sprints. They use Velocity to forecast the amount of work they can probably complete in the next sprint.
But, as is the case for many teams, they don’t deliver a production-ready solution increment in every sprint. The mean CT for their User Stories is around 8 weeks.
Now, assume this team is actively and mindfully pursuing improvement. After a couple of months, they reduce mean CT to around 6 weeks. After further improvement, it drops to 4 weeks. Later, it drops to 2 weeks. Their Velocity remains about the same throughout this improvement period, because their Definition of Done is changing as they improve their methods. With each incremental improvement, they’re able to bring User Stories closer and closer to “production ready,” until they finally achieve that goal. At that point, CT and Velocity are equivalent. Prior to that point, CT and Velocity have different meanings and are used for different purposes. Thus, they are not directly convertible (except as an exercise in arithmetic).
That’s my two cents’ worth, anyway.
Thanks for your comments, Dave. Certainly you cannot compare Lean metrics with Agile metrics unless you have some understanding of both.
In the example you describe, strengthening the Definition of Done is equivalent, in Lean terms, of measuring the cycle time over a larger span of the value stream. When viewed this way, the comparison makes sense. The numbers may not be easily comparable over time for the same reason that they wouldn’t be in a Lean process model if you change your measurement points.
Thank you for this great post! I’ve translated into french : http://wiki.ayeba.fr/Relations+entre+temps+de+cycle+et+v%C3%A9locit%C3%A9
… and a very good Christmas and New Year 🙂
As far as I understand Little’s Law your example assumes a WIP of 1:
“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.”
Most teams I know work with a higher WIP. Then the relation would be:
avg(Cycle Time) = avg(WIP) / avg(Velocity)
Thanks for your comment, Stefan. It really made me stop and think.
The article I posted on Cycle Time clearly states “Cycle Time (CT): Average time between completion of successive units. It is directly related to the output rate. A process with an output rate of 4 units per hour has a cycle time of 15 minutes.” Our velocity is the output rate in stories per iteration.
You state Little’s Law as “avg(Cycle Time) = avg(WIP) / avg(Velocity).” I think there’s a problem with this statement. I can see Cycle Time being Little’s “w” or “average time in queue” (using http://www.columbia.edu/~ks20/stochastic-I/stochastic-I-LL.pdf for reference on Little’s Law) and WIP being “l” or the “length of the queue,” but “λ” or “arrival rate” is not the velocity. Velocity is a count of stories. Arrival rate must be measured in units per time, so in this case the average would be velocity (stories) per iteration (days).
I’m afraid my math is too rusty and my mind is too tired to analyze this further, tonight.
After a night of sleeping poorly while my mind struggles with this, I’m dissatisfied with my response. Yet clearly the definition of average cycle time does not change. If a team of 15 (not recommended) starts all 15 stories at once (not recommended) and works on the individually (not recommended) and spends 10 working days each, then while the individual cycle times are 10 days, the average is still 2/3 day because we have 15 “story processors” working in parallel.
Perhaps someone else can point out the flaw in our application of Little’s Law to this situation. Perhaps it’s due to the fact that we have an implicit input queue “To Do” and output queue “Done” that we’re mixing into some parts of our calculation. Perhaps it’s that we always have a number of “processors” equal to our WIP.
Some definitions: “Average time between completion of successive units” provided the customer accepted the deliveries is called Takt Time as seen here http://www.lean.org/Common/LexiconTerm.cfm?TermId=337
So Takt Time is the pace at which customers can accept delivery or the pace at which the system can deliver.
For example if for a given time period T=10 work days the system delivered N=15 user stories and the client accepted them then:
Takt Time(TT)=T/N=10/15=2/3 work days per user story exactly as George says.
Takt Time is measured in time as you can see by the above formula.
If we use the same data from above we can calculate Average Throughput (TH)=N/T=15/10=1.5 user stories per day
It is visible that Takt Time is reciprocal of Throughput.
Little’s Law states that Average Throughput (TH)=Average WIP/Average Waiting Time in the System (LT)
Since we know that TH=1/TT we can express Little’s Law using Takt Time and get:
Takt Time (TT)=Average Waiting Time in the System (LT)/ Average WIP
Using this formula we can see that if WIP=1 then Takt Time equals Average Waiting Time. For example if for a given time period T=10 work days the system delivered N=15 user stories and average WIP=1 them then:
TT=LT/WIP=LT/1=LT or LT=1*TT
Since TT=N/T=2/3 then LT=1*TT=2/3 days
But if we have average WIP=2 then TT is still 2/3 days BUT since TT=LT/2 or LT=2*TT then Average Waiting Time (LT)=4/3 days.
Average Waiting time is called Cycle Time, Lead Time, Time in Process, Flow Time…
Conclusion – when average WIP=1 then the Average time between two successive deliveries equals the Average time to deliver a work item.
Disclaimer – the above application of Little’s Law assumes the Little’s Law holds for the system.
In my opinion, the Kanban equivalent of Velocity is Throughput. Therefore, Cycle Time and Throughput are true reciprocals of each other.
As you already indicated in your definition, Story Points add noise to Velocity. Therefore, Cycle Time and Velocity can only be considered true reciprocals of each other when Story Points are replaced by a noise-free measurement unit.
Nice post, George. I’m a year late, but I was pondering the relationship between velocity, cycle time, and Little’s Law.
Here’s how I think it works.
Little’s Law: Cycle Time = WIP / Velocity
Let’s say that you give 5 equal-sized stories to team A and to team B.
Team A delivers nothing until the end of 5 weeks, when it delivers all 5 stories.
Team B delivers one story a week.
Both teams have the same average velocity: 1 story/week.
Team A has higher cycle time. Each of 5 stories took 5 weeks. So that’s 5 weeks/story. For Team B, each of 5 stories took 1 week. So that’s 1 week/story. The difference between the two is explained by WIP. Team A had WIP of 5 and Team B had WIP of 1.
Let’s say that we measure Lead Time instead of Cycle Time. i.e., we measure from the time that the stories hit the backlog and not from the time that the team began work. Team A still had average lead time of 5 weeks/story. But Team B had average lead time of 3 weeks/story. (1+2+3+4+5)/5.
Now, let’s say that Team B2 is less efficient and took 20% longer for each story because they were working together instead of working in silos. So they deliver 1 story every 6 days. That’s a Cycle Time of 1.2 weeks/story, better than Team A’s 5 weeks/story. Team B2’s Lead Time is (1.2+2.4+3.6+4.8+6)/5, or 3.6 weeks/story, also better than Team A’s 5 weeks/story. Team B2’s velocity is worse, though: 0.83 stories/week.
So would you rather have Team B2 or Team A? If you’re trying to maximize velocity, you’d pick Team A. If you’re trying to minimize cycle time, you’d pick team B2.
Technically, you’d have to measure the delay costs of your five stories and compare those delay costs to the capacity cost of your team. If your delay costs are greater, then team B2 (which has smaller average delay) wins. If your capacity costs are greater, then team A (which takes less overall time) wins.
In most real-life product development scenarios, delay costs are a lot greater than capacity costs. So it’s reasonable to assume that you should minimize cycle time.
What you say is true. Velocity is the reciprocal of the average cycle time integrated over the length of the timebox. Shorter timeboxes and swarming over the stories within the timeboxes are well-established techniques for improvement. For software development, this always seems superior to parallel execution.
But they aren’t reciprocals! They are PROPORTIONAL to their reciprocals. But they aren’t reciprocals at all. If they were, then two teams with the same velocity would always have the same cycle time. In the example I gave above they don’t.
Phil, they are averaged over the length of the timebox. Your example is looking at the differences within the timebox. Summary numbers from the timebox cannot resolve those differences. It’s a sampling problem. Check the work of Nyquist.
BTW, if you look at cycle time in manufacturing, they also use average cycle time based on parallel work. If you add machines at a step, the average cycle time goes down even though the amount of time to process a single unit does not change.