Velocity vs. Cycle time — or ‘How to predict how much work will get done by a given time’

Both velocity and cycle time make predictions based on completed work in the past. This approach is sometimes referred to as ‘yesterday’s weather’. For the remainder of this post, I will assume that this work is chunked into user stories. Basing predictions on past events assumes a stable (enough) context. In our case, the most important factor here is a stable team.

In either case these user stories can be estimated — usually with story points — or split to roughly the same size and then just counted. The later being faster and more outcome-focussed. Assuming same size stories simplifies measurement and calculation in both cases and is just as accurate as using more precise estimates, but requires more care when creating stories. For the remainder of this post, I will assume that user stories are roughly the same size and counted instead of using more detailed estimates. If you are a firm believer in estimates the following also holds true but requires an extra step of converting user story points into number of stories.

Velocity measures completed stories per iteration. The unit is work per time, e.g. 4 stories per 2 week iteration.

Cycle time measures the amount of time passed working on a story. The unit is time per work, e.g. 2.5 days per story.

Velocity and cycle time can be (sorta) converted into each other (neglecting times in between finishing and starting user stories and in the simplified case of WIP = 1) and are, therefore (kinda) equivalent in the information they carry. They merely represent different points of view on the same thing — how long does it take to get chunks of work done. For a more in-depth discussion on the actual math, check out the comments on this blog post.

Another concept of planning is commonly mangled up in discussions about predictions but is actually orthogonal to it: Iteration planning vs. variable input queues.

Iteration planning fixes the scope for the next iteration, e.g. 4 stories in the next 2 weeks. Velocity is often used in this context, since the unit of velocity, work per time, can be used to support the decision how much to forecast for the next iteration.

A variable input queue provides a steady stream of work. User stories can be re-sorted, added or removed anytime as long as work on them hasn’t started yet. This provides more flexibility compared to iteration planning. Measuring time per user story (cycle time) matches this well.

When using a variable input queue and no iteration planning, iteration goals and the associated commitment also disappear. This can be replaced with commitments to OKRs, which we do quarterly. Three months are long enough to accomplish significant things, while still short enough to have a sense of urgency.

Fixing the length of the input queue provides a mechanism to trigger refilling the queue as well as preventing planning too far into the future. The optimal queue length depends on story size, team capacity and predictability of stories. An amount of stories that everyone can easily keep in their heads (around 7) prevents overhead in reviewing and re-prioritizing the queue. When using a fixed input queue planning is triggered by an empty slot in the queue rather than in specific intervals. It also is finer-grained — possibly one story at a time. When integrating this in a daily standup, an extra planning meeting can be avoided.

Additionally to tracking the time a story is worked on (cycle time) one can easily also measure the time from when a story is added to the queue until it is done (lead time). This makes it easier to get an idea by when a story will be finished once it is added. This is very effective if visualized at the end of the queue with something like “Your expected wait time today from this point is between x and y days.”, aka Disneyland wait time.

Velocity is usually used with iteration planning and cycle time with variable input queues. This feels more natural because measuring work per time with iterations is a good match, as is measuring time per work on a variable input queue. But there is nothing preventing you from combining it differently if it makes more sense in your context.

Discussions about velocity vs cycle time are a substitute discussion for iteration planning vs variable input queues. This is where the real differences are. Velocity and cycle time are merely different points of view on the same thing. They just happen to match one approach more than the other.