Velocity vs Cycle Time

Many teams measure velocity. However, cycle time often provides a more accurate measure and better data. I’ll discuss when you might use each.

Kathy, a tester, knew there was something wrong with the way this new-to-her team worked. Her previous team had used velocity to estimate their stories for the iteration. This new team also tried to use velocity, but they never quite estimated correctly. This new team used the same techniques. But, they almost always fell short of what they thought they could finish.

In her first retrospective with this team, Kathy asked this question, “Is it me, or do we seem to have trouble using velocity to estimate what we can do in an iteration?”

One of the developers, Dan, grinned. He said, “Oh, it’s all you. No, seriously, we never seem to get it right. Have you seen velocity work?”

“I have,” Kathy said. “On my previous team we used velocity and we were spot on with our estimates.”

“Do you know what’s wrong?” Dan asked.

“I have a suspicion,” Kathy said. “But I need to gather some more data first. I don’t think we’re all wrong. I think our context is different than my previous team. Is it okay if I gather more data?”

Dan frowned. “You can. But why don’t you tell us what you’re thinking and we can help gather that data?”

“Okay,” Kathy said. “But I could be wrong. As long as you know that.”

Dan and the rest of the team nodded.

“I think we have too many wait states,” Kathy said. “You guys develop larger chunks than I’m accustomed to. I’m not saying that’s wrong. But, then you have to wait until you’re done developing before you do code review.”

Dan nodded. “True,” he said.

“After you guys are all done with your code, I get to test it. And, because you merged several pieces of functionality, my little tests aren’t enough. I have to write more tests. I don’t always finish before the end of the iteration.”

“Yeah, I noticed that,” Dan said. “But, it does mean you have work at the start of the next iteration.”

“True,” Kathy said. “And, we can’t take credit for partially completed work. We account for all of that story’s points in the next iteration. So, instead of our velocity being a somewhat standard 32, we go up to 39 or 40. Or, we go down to 25 or even 20. We’re just not consistent.”

Sam, another developer asked, “What’s really the point of consistency? So we get 32 or 20 or 40 points? Does it really matter?”

“It only really matters when an external date is on the line and we can’t predict when we’ll be done,” she said. “Yeah, it matters to us, too. But when a product manager or a salesperson wants to tell an important customer, and we don’t have good enough data, we look like fools. Worse, the people make dates up if we can’t be consistent.”

Dan nodded. “We’ve been there.”

“That’s only half the story, though,” Kathy said. “What really counts is we don’t know why we have delays and where those delays are. Some of the development delays turn into testing bottlenecks. You know how you’re waiting for me to finish the testing?”

Most of the team nodded their heads.

“Yeah, I become a bottleneck because the work I get is too large for me to finish faster.”

“We’re going as fast as we can,” Sam said.

“I agree,” Kathy said. “That’s why I need to gather data. I can’t tell if it’s the size of the work, or the handoffs between the developers, or the final handoff to me. It might not be any of that. It might be that Prudence, our PO, isn’t around enough to guide us. I can’t tell. I need to measure the cycle time.”

Dan said, “That’s a great idea. Let’s all do that, not just you. Fist of five, everyone?”

Every team member held up either four or five fingers, signaling their agreement.

“Excellent,” Dan said. “We’ll measure cycle time and then decide what to do in our next retro.”

Velocity Is Not Just Story Complexity

Many agile teams think of story points as a way to see the story’s complexity. However, story points don’t tell the entire story. Story points don’t take the team delays into account.

Cycle time is the measure of how long it takes a team to complete an entire story, and the cycle time includes the delays. It doesn’t matter how complex the stories are. Teams can measure their cycle time and use an average cycle time to predict what they can complete in an iteration, or when the team can finish certain features.

It all depends on how long the average cycle time is for the team.

Kathy’s team had these questions about their cycle time:

• Are our stories larger than we might like?
• Do we have more handoffs and cycling back to previous states?
• How long does work wait for us to finish?

Without data, Kathy and the team can’t know if any or all of these ideas are true. They don’t even know if the problem could be elsewhere. That’s why they need to gather data.

Map Your Team’s Value Stream

A value stream map shows you a team’s various work and wait states. Someone (or people working together) take an item off the Ready column and start to work on that item. They work on it until they can do no more. Do they need to wait for someone? If so, the work goes into a wait state until the next person can take the work. That person then works on the item and when they’re done, the item waits for the next person. That repeats until the team has finished the work item.

Add all the times, for all the work states and the wait states. That’s the team’s cycle time for that item. If a team swarms or mobs on the work, all the time is work time. There is no wait time.

However, in this case, Kathy knows that the team uses several work states: in development, in code review, and in test. That means there is a wait state between all the work states. And, if someone finds an issue in code review, the work might cycle forwards and backward until the team finishes the work.

It doesn’t matter if your team is collocated or distributed. When teams don’t work on one item at a time, they incur wait states. Once you see your value stream, you can calculate the cycle time.

In the next iteration, Kathy calculated these cycle time measurements, with the help of her team:

At the next retrospective, the team wasn’t done with Story 3. However, even with this limited data, they could see some of their problems:

• Their stories were too large. Any time a story stayed in Code Review for 2 days, that story was too large.
• They had to wait for Code Review.
• They had varying work time and wait time, but they appeared to be able to do not more than 2-3 stories per iteration, because of their cycle time.

They knew they had to change something. The created several possible experiments:

• Always pair so the developers had built-in code review.
• Create smaller stories.
• Check smaller chunks into the code, so they could review more often.

They decided to start with checking smaller chunks into the code first. That would allow them to review more often.

Measure the Experiment

The team still had to complete Story 3. Then they could see if their smaller chunks worked. That worked better for reducing the time waiting for code review, but Kathy still needed the entire chunk so she could test and know if the item met the acceptance criteria.

Over the next three iterations, the team tried pairing more often. That also helped. Then they tried swarming and that reduced their wait time dramatically.

After two more iterations, they asked the product owner to work with them to create much smaller stories. They wanted to create one-day stories.

They’re still working on how to create one-day stories. And, even without stories that small, they have their average cycle time down to 2.5 days. That means that for a 10-day iteration, on average, the team can complete six or seven stories.

That’s good enough estimation.

Decide When to Use Velocity or Cycle Time

I no longer use velocity to estimate or predict. I only use cycle time or count stories. The larger your stories, the less predictable your cycle time is. I find that measuring cycle time becomes a forcing function for the team to create and finish smaller stories.

If you’re not sure what to do, visualize your team’s work states and wait states. Measure the time the team spends in each of those states. Then, you can create options for experiments or changes.

Velocity might be useful for your team. However, cycle time will offer your team more value over the long run. You can see and measure how much time your team spends in the work states and the wait states. And, you can see alternatives to create better flow through your team.