Cycle time: a metric or a goal?

In this post, I want to share something I learned in the past months. For a long time, our team is collecting a small number of metrics to see how we’re doing. Cycle time is one of those metrics. For a long time, we pursued to reduce the cycle time, because we know that reducing the cycle time increases our output, but of course we also are continuously improving in other areas as well. But recently, we discovered something new.

Read more: Cycle time: a metric or a goal?

What is cycle time?

First of all, let’s talk a bit more about what cycle time actually is. The cycle time can be defined for a given task: it is the amount of time it takes to complete the task. It is measured as the time between the start and completion moments of the task.

Yet, there can be multiple definitions of ‘start’ and ‘completion’. Some define ‘start’ as the moment that the task was put on the team backlog, others take the moment that the task was moved from To do to In progress on the sprint board. Likewise, ‘completion’ can be defined as the moment the task is moved to ‘Done’, but it can also be defined as the moment that the customer can actually use the software. Which one is useful depends on the specific situation, and it also depends on what you want to improve. The latter means that you need to choose carefully: choose the wrong metric, and you might be improving in the wrong direction.

In our team, we measure the cycle time as the time that our stories are in progress on the scrum board. This helps us to improve as a team.

What increases cycle time?

One experience we have with this: it acts a lot like a rear view mirror, as it gives a view of the past only. After all, cycle time can only be calculated at the moment a task is actually done, so only tasks that are finished can be part of the cycle time calculation.

Yet, the metric is useful. It makes past problems visible so we can distill lessons from it instead of forgetting about it. It also shows that we actually solved a problem when cycle time goes up first (when an impeded task was finally finished) and then down again (when we’re back on track).

We also see that the cycle time is not constant. There are a lot of things that affect the cycle time. Sometimes we run into unexpected issues that need to be solved first, making the task take longer than planned. But there are also other contributing factors, like changes in the team, work environment, way of working or legacy code. There may be changes in release processes that may improve or worsen the cycle time. Or, depending on the type of company, there may be quality procedures that you need to adhere to.

Unexpected cycle time improvements

We found that cycle time is also affected by how we work within the team. Of course, we knew that for a long time when we were searching for measures to reduce the cycle time. But there is more.

We learned that lesson recently, when we wanted to work together more closely. We decided to focus on pair programming, to make pair programming part of the team culture. We saw the advantages of this, without taking cycle time into account. Yet, as we improved on this part, we saw the cycle time drop.

Another experience was when our team was reduced in size: this also turned out to result in a reduced cycle time for our team. In fact, a smaller team makes cooperation within the team a lot easier.

Two approaches

So to summarize, there are two possible approaches to reduce cycle time.

The first one takes cycle time reduction as a goal and focuses on finding direct measures to speed up completing tasks. It finds ways to reduce impediments and tries to prevent tasks that have a large cycle time to enter the sprint.

The other approach seeks to improve the team as a whole. It looks at forms of waste, but also the softer aspects of working together more closely, have better expectations, have clear boundaries and so on. Cycle time reduction is not the main objective, but it happens to be a positive outcome nonetheless, apart from other benefits.