Cycle Time: a simple yet powerful tool to help software businesses and teams improve predictability and optimize their processes

Predictability and process optimization are two important success factors of the software business. How can we objectively tell that a decision actually optimized our performance? How do we confidently communicate that a certain feature will be available at a certain date? Those are tough questions to answer when dealing with complex work where many variables are at play that we just can’t control.

Measuring the Cycle Time of the work in your project will let you discover interesting patterns in your system’s behavior, allowing you to hypothesize optimizations, and get objective data on whether these optimizations worked and by which amount.

Before going any further, let me give you the definition of Cycle Time: “The amount of elapsed time between when a work item started and when a work item finished.” (from the Kanban guide on ProKanban.org)

That broad definition can be unpacked as follows:

• Elapsed time: Normally I would use “days” as a unit. What is important is to use the same unit across your calculations, and not mix up days with weeks.
• Work Item: Any type of work. It can go from team-level work, such as user stories and bugs, to broader work such as features, epics, capabilities, etc. What’s important is to ensure that you measure identical types of work the system performs. For example, measuring the Cycle Time of a team’s work like user stories, tasks, and bugs, or measuring the Cycle Time of epics of a business department.
• Work item started/finished: in your context, what boundaries are you interested in measuring? For example, team-level boundaries could go from the date they put the work item “in progress” to when they consider the work finished (done), or when a requirement was created to when it’s deployed in the customer. What matters is to define the (initial) boundaries and start measuring. Later you can come back and redefine.

Additionally, with Cycle Time you open the door for forecasting delivery dates of your projects with a high degree of certainty. It is THE cornerstone of the scientific approach to forecasting.

Many software management tools like Jira, Trello, Azure, etc, typically track the dates of state change of the work items behind the scenes. This means that if you use one it’s likely that you already have all the information that you need.

Sounds too good to be true? Well, let us dig in and see how it’s done.

How Cycle Time helps with predictability

To illustrate how Cycle Time helps with predictability in software projects, let us start by forecasting a very simple project.

This example might look silly at first glance, but hang in there, it will make sense.

The “tennis ball throwing” project:

• Goal: Hit the target 100 times by throwing a tennis ball.

Project constraints and assumptions:

• One person (you) does the throwing
• To simplify the calculations, you always take 1 minute to aim and throw the ball
• You’re 12 meters away from the target (the length of a bus)
• It’s a perfect fresh sunny day: no wind, no rain, no noise, no air pollution
• The target is about the width of 2 adult people side by side.
• It’s expected that you miss the target sometimes

Question:

• How long would it take to finish the project?

Well, we could easily estimate, for example, that you’d probably miss half of the shots, and we could go for around 200 minutes to finish the project.

Ask yourself: would you go with a different estimate? If so, how confident would you be in communicating it to stakeholders?

That’s precisely the situation we find ourselves many times in software projects. We provide an estimation or a best guess, and the date and budget expectations are locked. In some situations, we add “buffers” to make sure we deliver on the “promised” schedule.

Now, let’s look at the problem from a different angle.

Before asking you for an estimate, I would have you throw the first 20 balls, then we would measure the throws and analyze the data to provide the estimate.

Here is the result of one such possible measurement:

• That’s 35% throwing accuracy (I know, I know — I’m sure you’d do better 🙂).

Now that we have factual data on how the system behaves, based on it how easy is it to provide a forecast of the project?

• Knowing that you already hit the target 7 times out of 20 throws, we get ~300 min (279 min for 93 throws on target + 20 min already spent). Since we are taking all data into account, we can say the forecast comes with very high confidence: 99%.

Well, maybe 99% confidence is too high for the nature of our project, and we can cope with some risk. What would be the estimated cost for 85% certainty? By removing the outliers and taking 85% of the best shots, we get:

• 42% throwing accuracy
• Estimation: 257 minutes with 85% chance.

What’s interesting is the introduction of the risk factor in the project. We can go on with different risk levels (70%, 60%, 50%), and we’d see different costs for different risk levels, and have a clear understanding of the trade-off between cost vs risk.

Now that we understand the data and different risk levels in the estimation, would you go with a 50% risk level in your project? Most likely not, but: isn’t that exactly what we do in when taking the “average story points” or “average velocity”?

When we use average values for forecasting, we’re relying on the central point of the data. This means that half of the data is above the average and half is below. By doing this, we assume our plan is generally fine and ignore important details about how our system operates and how the data is spread out. It’s like tossing a coin and expecting it to always land on its edge. Could this be why many Agile projects face difficulties?

Also, what if we continue to collect data as you throw the balls until the end of the project? What if we see that your accuracy is declining? What decisions could be made based on this new information? Should we set a new project goal of 80 hits? Would it help if we reduced the throwing distance to 10 meters? Would it help if you take a 5-minute break every 10 throws?

That’s the power of measuring and visualizing data: you immediately form hypotheses, make the necessary adjustments, and get immediate feedback on whether it was a good or bad decision.

How does this simple example compare to software development? Software development work is far more complex, there’s far more uncertainty and the size of the work has a lot more variation than throwing tennis balls.

Aren’t those good reasons for us to stop relying on estimation for forecasts and start measuring actual data? That’s precisely what cycle time is: data that helps us to improve our guesses and to allow proper forecasts.

So, if you take all the “throws” in a software project (completed work) and plot them in a graph, you get a scattered view very similar to the target we used for the simple project:

That graph is called a Cycle Time Scatterplot. We can read it as follows:

• Each dot is a user story, bug, or task (work item) that was closed in the project
• On the x-axis is the date when the work item was closed
• On the y-axis is the actual number of days it took for the work took from “in progress” to “done” (these are the boundaries in this case)
• Some work items took a few days, and some other few work items took (much) more than 30 days
• And you see the line that defines the upper boundary of 85% “best shots” (percentile line). In this case, it means that 85% of the work items took 22 days or less to get done.

If someone asks us how long would it take a work item to get finished once the team starts it, how would you respond? Probably be something like this:

• Based on our current Cycle Time the team would take 22 days or less to finish that work with an 85% chance.

Would that be a fair response?

You might argue that that specific work item is simple enough to get finished in a handful of days if it’s prioritized high enough. That’s true, but the system’s Cycle Time is 22 days at 85%. Unfortunately, we cannot conjure days from thin air, so whenever you prioritize work, some other work that is already in progress will have to wait, accumulating days and most likely increasing the overall Cycle Time of the system.

Unfortunately, the linear math we did to forecast the simple project of “throwing the ball” will grow far too complicated or even impossible to apply to software projects. When it comes to complex systems that are hard to predict, science has been relying on sampling and simulation methods. For example, to predict Covid-19 spreading dynamics the Monte Carlo method and probabilistic forecasts have been applied.

Fortunately, Cycle Time is the foundation to tap into this sophisticated way of projecting the future. To understand more about forecasting multiple work items or a full project, please refer to my other article: Improve Predictability of Software Projects with Probabilistic Forecast

How Cycle Time Helps with Process Optimization

If you got this far, you probably already figured out how Cycle Time would also help organizations and teams to improve their processes.

With a Cycle Time Scatterplot you can easily spot patterns and create hypotheses and new experiments to improve your workflow. For instance, based on the Scatterplot above you may ask:

• Why did that outlier take almost 100 days to be finished knowing that the team doesn’t pull work more than 8 story points into the sprint? What happened there? What could we have done differently?
• Why are there a couple of work items that take more than the expected duration? Should we create new work items for later whenever new work is discovered, and keep the focus on closing the work item at hand?
• What can we learn and double down on about the work that took less than expected?
• Etc.

The fun part is: whatever new thing you try or do to optimize your system, it’s immediately fed into the data, and you see the results in the Scatterplot almost immediately, either confirming or discarding your hypotheses. How cool is that?

Furthermore, as I mentioned: the Cycle Time is the cornerstone of more sophisticated practices such as Flow Management and Kanban. The following ideas from Kanban are well-thought practices created by experts in this field that you can immediately apply to likely optimize your workflow, and hence your Cycle Time and business predictability. Those are:

• Limiting the work in progress
• Actively managing work item aging
• Defining workflow and policies
• Defining service level expectation

I hope that this article will be helpful for you and your project. If you have questions about it or how to get started, or if you would like to share your own experiences with Cycle Time or your thoughts on it, get in touch! I love discussing Agility topics over coffee.

In case you would like to try it yourself and see how Cycle Time Scatterplot looks like in your project you might want to try the ActionableAgile tool from 55degrees.

If you’d like to dive a bit deeper into these subjects, check out:

- Book: “When will it be done?” from Daniel S. Vacanti

- Guide: “Kaban Guide for Scrum Teams” from Scrum.org.

- Guide: “The Kanban Guide” from ProKanban.org.

I want to send a big thank you to my esteemed colleagues at diconium who reviewed the article and helped to improve it.

To my son and wife who must share my attention with my passion for Agility.

Thank you.