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. They work in parallel with Tim, the tester. They 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:

Domo Arigato! (If I said that right.)

18 Replies to “Measure Cycle Time, Not Velocity”

  1. Either there are some typos here, or I’m being dense. I vote for #2, but my self-esteem insists I my questions as if it’s #1.

    “Before saying the team’s average cycle time is 5.25 days, I would measure more stories.” — did you mean to say hours not days?

    “Maybe the team more often takes 2 days to finish a story.” — does 5.25 hours translate to two days somehow?

    “If your team always finishes two stories in an iteration, you have a cycle time of 5 days.” — I totally can’t figure out how the math works on that.

    1. Chris, typo!! Yes. 5.25 days is supposed to be hours. I will fix that in the text.

      In the para with “Maybe the team more often takes 2 days to finish a story.”: That’s just one story, the one that takes 5.25 hours (not days as you correctly pointed out.) However, you can’t just measure the cycle time for one story and know how long the average/median story takes. I was offering options, as in maybe 5.25 hours was a really fast story. Maybe the team more often takes two days for a story.

      Lower down, I said: “If your team always finishes two stories in an iteration, you have a cycle time of 5 days.” Here’s I’m taking the total time the team works on a story. In one iteration, your team might finish one story in 3 days and another story in 7 days. Total of 2 stories. Average cycle time of 3+7 (10 days for both stories) divided by 2 stories = 5 days cycle time.

      Maybe in the next iteration, the team finishes one story in 2 days, but 8 days for another story. Still cycle time of 5 days. The problem with such wide variance is that you lose the ability to create a better prediction. I would definitely use a Monte Carlo simulation (probabilistic scheduling) to see the worst cases. (I didn’t address how to do that here.)

      I often see teams who manage to finish two stories. They have all kinds of reasons for doing so. They keep thinking they can do “more” because their velocity says so. But, they can only finish two stories. When they move to measuring their cycle time, they start to see why.

      1. Thanks very much, Johanna. That clears up the math details. Still pondering how this helps the team focus correctly. Would tallying wait time do the same? It wouldn’t catch the problem of stories being too big, but should that be included in the same metric? Again, thanks for the fast response.

        1. Chris, if you only look at the aggregate of wait time, you can’t see the wait states. Does the team have an available tester or UI person? Does anyone need to wait for someone outside the team for an answer? What about deployment? That’s why I suggested the team map the value stream. Yes, with a picture.

          When the team sees their actual flow of work, they can decide if they like that flow or if they want to change how their work flows through their team. Velocity doesn’t discuss that at all, which is why I no longer recommend velocity as a measure.

          When people see their flow and their wait states, they can ask more questions. I worked with an organization who had problems as in Unearthing Your Project Delays. The managers thought the teams were “lazy.” The managers could not believe how long things took. (Literally) Any given story was a small number of points. But the wait times overwhelmed the work time. (That article doesn’t have the value stream map as an image. I think you can visualize the wait times. If you would like me to show the value stream map, let me know. I’ll do another blog post so you and others can see the wait times.)

          Actionable information is power. Visualizing the cycle time to see the flow, and calculating the wait times can help a team decide what to do next to improve.

          (I can respond fast when I’m in my office as I am now. Thanks.)

  2. Why not measure both? Measuring both will help isolate impediments (cycle time/lead time/takt time) and help encourage the team to improve estimation and scoping of work. “Beating the last goal” is a huge motivator for the teams I have worked with and Product Owners really like being able to have something tangible to forecast with (velocity). As long as doing both doesn’t add an impediment I would suggest two points of measure over one.

    1. Shaun, I think I’m missing something. I’m not sure how “beating the last goal” in terms of velocity makes sense. (At least, to me.) I have these questions:
      – Why is a set of stories or velocity a goal? (I might not understand what you mean here.) I understand a sprint goal, but I don’t happen to subscribe to it.
      – If velocity is a goal, why not reduce cycle time? That would allow more stories, which is the point, not more story points.
      – You can use cycle time (or counting stories) as a much better (more empirical and more grounded in reality to) forecast than velocity.

      (I feel another blog post coming on :-). You raise interesting issues about how a team can create a competition with itself to better itself. I don’t quite see how velocity does that. I do see how cycle time does that.

  3. Interesting points. How would you suggest getting the team involved in visualizing the cycle time? I wouldn’t want it to feel like this is somehow a measure of their success but rather getting them involved in identifying potential or present gaps and then coming up with experiments to address these gaps.

    1. Nic, I’m with you re wanting to make sure the thinks in terms of gaps, not that they aren’t successful. Here are several circumstances where you might suggest measuring cycle time:

      • If the team feels under pressure to do “more” in a given iteration
      • If someone thinks the team is “too slow” now
      • If the team thinks they could do more and they don’t know where the time goes.
      • If the team has an action from their retrospective to already consider an experiment

      If you serve the team and you see delays, you might say, “Hey, do you know about this tool called a value stream map? I think I see delays in the team. I’d like to map/us to map the value stream for a few features/next two weeks and see what we learn.

      Every time I’ve been successful with the value stream map, I’ve stressed that it’s a learning tool, not an evaluation tool.

      One of my clients says that he asks each of his teams to measure their cycle time. They often have delays because of cross-team dependencies. (See Product Roles, Part 5: Component Teams to Create Slices.) He needs the data to work to create cross-functional teams and make smaller stories across the organization. He’s been at this for several months. The first month, his colleagues didn’t believe the data. Now, his colleagues believe the data and the managers are finally collaborating.

  4. Hi Johanna,

    We are working solely with measuring velocity and it works pretty (even perfectly) well, which makes this article very intriguing. We are a very small team and although people did come and go at some point, we do have calculated a “per person” point average, which allows as to really take that into account …

    That said, we do have that phenomenon that for a story there are waiting times (requested reviews etc). They are though compensated by already starting another story …

    Even though I don’t see at this point a reason to change (for us), I’m curious though “how” you measure the waiting time?! I mean, through what tool?

    Thanks again for the article


    1. Hi Toni, I measure waiting time in as easy a way as possible: If I use cards, I mark the start and end times of work time, often on the back of the card. I mark the start of the wait time and the end of the wait time.

      If you use a tool for your cards, most tools have a way to track when the work gets into which column and when it leaves that column.

      You said that people start another story when waiting for review, right? That’s a form of multitasking. I recommend against that, and that people work in pairs to not have to wait for review. I have a ton of content about that. Maybe see my flow efficiency series, or the pairing, swarming, and mobbing post.

      If what you do works now, you might not want to change it. But, I worry about measuring anything per person when it takes a team to succeed.

      Thanks, glad you liked this post.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.