Why cycle time can tell you more than velocity

Facebook

Twitter

Linkedin

It will be an uncertain plan for sure 🙂 

Let’s look closer into the problem, what does velocity depend on?
Let’s try isolate some factors

1. Estimation (how difficult we perceive it is going to be)
2. Amount of work in progress (how much else we must complete)
3. Staffing (how many people)
4. Time it takes to implement the smallest piece

It might be possible using statistical analysis to tell which of these factors that have the biggest impact. But that is outside the scope of this article.

I am going to make the argument that a high variability of any of these factors can hide out understanding of our real capacity. To do so, let’s pretend for a moment that we only have two factors, estimation and Time it takes to implement the smallest piece (we’ll call this our delivery process capability)

The "plotted" row is a visual demo of how the variance of a series of stories adds up to the velocity.  The "math" row shows how variance for a sum of two variables is calculated.

This makes it feasible to expect that the variance of the estimation process will dominate the variance of Velocity even if the real capacity to deliver is stable.

So how can we check how we are doing in our delivery process (our real capability)? We can use cycle time. Cycle time is less dependent than velocity on the factors mentioned above. Yes –  it has a dependency to complexity (if you prefer, story size) but even that can be dealt with by dividing stories in the right categories.

And now we can distinguish between:

Unstable….no hope of making predictable release commitments….

Ah, there is hope..  

And..

• If the delivery process is stable and
• The variance of the other factors is too

..we should be able to do good predictions 🙂 It is harder than it sounds…  for this we need to understand and at least harness the variance of estimation. But even if we can’t control it, there are a couple of smart moves we can do to limit the variance. I hope to come back to this in a later post 🙂

Let’s sum up what we learned:

• Velocity is often too distorted to provide relevant feedback
• We need better ways to learn about our deliver capability
• Cycle time is one such mean