Cycle time is an under-appreciated metric that can provide insight into the effectiveness of a development team. Velocity (aka throughput) is usually the metric that gets all of the attention. However, shifting some of the emphasis away from velocity and onto cycle time will probably increase your velocity anyway, and the customer will benefit as well.
What Is Cycle Time?
Cycle time represents the amount of time it takes for work to flow through a system. To oversimplify some otherwise very interesting math, Little’s Law basically states:
Cycle Time = (Average WIP) / Velocity
A high velocity with a low average work in process means you have a low cycle time. A low cycle time means that once a team begins work on a feature it will generally be completed fairly quickly. A high cycle time means the opposite.
How Do We Improve Cycle Time?
You can decrease your cycle time by increasing your velocity, by decreasing your work in process, or by breaking your work into smaller chunks (although this isn’t as obvious from the formula). Four separate 5-point stories will flow through the system faster than a single 20-point story. Since increasing your velocity is typically difficult to do, decreasing your work in process and breaking stories into smaller units is usually the most practical way of improving cycle time. Imposing limits on the number of stories or points that can be in development will help ensure that the emphasis is on pushing existing stories through the system rather than starting new ones.
Why Is Cycle Time So Important?
Imagine you had a project with 100 well-defined user stories. Would the customer rather have one story delivered per day for 100 days or would they rather have 100 stories all delivered on the 100th day?
In both of these cases the team’s average velocity over these 100 days is the same. However, in the first scenario the team with the low cycle time is able to show constant progress to the customer. A low cycle time also means it is easier for a high priority feature or bug fix to be delivered quickly.
Thin Vertical Slices and Cycle Time
I recently began working with two small development teams that are new to the concept of user stories and thin vertical slices. The teams were mostly used to doing development in the form of thick horizontal layers. In other words, they take a group of features and break the work into data access vs. business logic vs. UI development tasks. They completed all of the work in one layer then move on to the next. The result is usually a very high cycle time and lumpy delivery of features. It is likely in this model that features will be completed in batches and the hand-off to Quality Assurance (QA) can be overwhelming.
But why should we care? Of course the customer would usually prefer to see progress at frequent intervals but what if the they really only wants to see the final product? Does cycle time matter then?
Yes! The importance of cycle time is intensified when there is a hand-off in your process. An example would be the development team handing off a feature to QA for testing. Another example is QA handing a feature off to the customer for user acceptance. If the development team is doing work in thick horizontal layers they are likely dropping huge bombs of features on QA in sporadic intervals. QA can be left with nothing to do for days or weeks and then suddenly they become the bottleneck. This is wasteful and will decrease the team’s velocity. It can also place unnecessary pressure on QA which can have a negative impact on quality. Likewise, reducing the team’s cycle time will reduce waste, improve quality, and ultimately increase the team’s velocity.
Conclusion
Cycle time is an important metric that can be used to improve a team’s velocity by reducing waste and improving quality. Strive to improve cycle time by enforcing lower work in process limits or breaking down work into thin vertical slices of functionality. Teams with low cycle times can show constant progress to their customers, are more capable of reacting to unplanned work, and perform better all around.
Does your team pay attention to cycle time?
Musings of a Software Guy 