Measure Cycle Time, Not Velocity

I'm not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes. (See Velocity is Not Acceleration.)

Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish something on their board.

Cycle time indicates how much the team collaborates together and how small the stories are. We want more collaboration and smaller stories in any agile approach. That's why measuring cycle time creates a virtuous (positive) feedback loop.

Collocated teams who collaborate on small stories tend to have short cycle times. Distributed teams who can't collaborate, even on small stories, tend to have longer cycle times.

Here's how to measure cycle time:

• I like to use a value stream map to see the wait times and work times.
• Note every time the work changes state: is it a work time (above the line) or a wait time (below the line)
• Add all the work times together.
• Add all the wait times together.
• Cycle time is all the work time plus all the wait time.

Now, you have data. If the work time is similar to the total time, the team moves as fast as it can. If the wait time is similar to the total time, the team is not collaborating as much as it could. They have handoffs and wait states.

BTW, it's often not the team's fault that they don't collaborate. That's often the case that the managers ask team members to do work that's not the team's work, or if the managers believe in resource efficiency.

Let's walk through two different teams, one that collaborates and one that doesn't.

Map the Value Stream for a Collaborative Team

This team collaborates, often in triads. Stephanie and Dan pair on the development. In parallel, Tim creates tests. While Tim can't finish his work until Stephanie and Dan are done, everyone is available to see and resolve a couple of problems once Tim runs the tests.

They do have to wait for Peter to be available to review the story. However, once they are all available, they mark the story as done. This story has a cycle time of 5.25 hours, of which only .5 hours is wait time.

Since the wait time is less than 10% of the total time, I wouldn't worry much about that much wait time. I might ask the team if that's okay, but I wouldn't stress until I had more data.

Before saying the team's average cycle time is 5.25 hours (originally a typo, now fixed), I would measure more stories. What is the team's average? Maybe this was a really fast story. Maybe the team more often takes 2 days to finish a story. One story doesn't offer enough information. What does matter is wait time for the various stories.

I like to measure cycle time for a week or two to see what the cycle times look like before I can use an average.

Map the Value Stream for a Team Where People Work as Individuals

This team works quite differently than the previous team. The people work as individuals.

Sam works alone and then asks for code review. It takes time for someone to be available. So, when Dan finds a problem, Sam asks Dan to keep an eye out for more problems. Then, Sam has to wait for a tester. Cindy is finally available 4 hours later. She finds problems with the code. The two of them clarify the intent of the story, so she changes her tests and Sam fixes his code.

Neither of them asks for more code/test review. That might not be okay. It depends on the team's working agreements about code or test review.

They then have to wait for the PO to become available to review the story.

Their team's cycle time is 18.25 hours. Look how much of that is wait time: 10 hours. More than the work time.

We don't know if the team thought this story was easy or difficult. But the wait time? That's very long.

The wait time for cycle time is why thinking in flow efficiency is so important. And, for thinking about how to collaborate as in pairing, swarming, or mobbing. Anything that keeps the team's WIP to one item will lessen the wait time in the team's cycle time.

Use Cycle Time to Estimate Story Duration

In Create Your Successful Agile Project, I recommend against velocity or using story points. Instead, I recommend teams measure and use their cycle time to see how long a story takes. (I also recommend you count stories. It doesn't matter what the points are. If your team always finishes two stories in an iteration, you have a cycle time of 5 days. You don't have to estimate anything. All you have to do is discuss the next two stories.)

Cycle time is real. You can count the stories, use your cycle time and generate a reasonable estimate. You could even run probabilistic scheduling to see what the most optimistic, realistic, and pessimistic dates are.

When I coach teams, I suggest that if they see a way to reduce cycle time, they should discuss that way anytime to see if they can reduce wait time.

See if you can measure cycle time instead of velocity. I'd like to know if cycle time works for you, too.

P.S. In response to a comment on this post, I wrote Thinking About “Beating” a Team’s Goal. Hope you enjoy it.

Update: This post is in Japanese: https://www.servantworks.co.jp/posts/measure-cycle-time-not-velocity/

Domo Arigato! (If I said that right.)