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.

]]>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.

]]>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.

]]>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.

]]>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.

]]>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.

]]>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.

]]>