Cycle Time Charts: What They Measure, Why They Matter, and a Free Kanban Template

Velocity gets all the attention. Cycle time does the actual work.

Velocity tells you how much a team completed in a sprint. Cycle time tells you how long each item took from start to finish. One measures output. The other measures flow. When organizations want predictability, which is one of the 9 Business Outcomes in the Path to Agility framework, cycle time is the metric that gets them there.

We've developed a free Kanban Excel reporting template that generates cycle time charts and spectral analysis charts for your team. Download it and follow along.

Editor's note: This template was originally published in October 2012 and has been updated for 2023.

What Cycle Time Actually Measures

Cycle time is the elapsed time from when work begins on an item to when it's done. Not when it was requested. Not when it entered the backlog. When someone started working on it to when it was delivered.

This distinction matters. Lead time (request to delivery) includes wait time in the backlog. Cycle time isolates the active work system. When cycle time is high, the problem is in your team's workflow. When lead time is high but cycle time is low, the problem is upstream prioritization or capacity allocation.

Why Cycle Time Matters More Than Velocity

Velocity has a well-documented set of problems:

• It's team-specific. You can't compare velocity across teams, which makes it useless for portfolio-level decisions.
• It's gameable. Teams that feel pressure to increase velocity inflate estimates. The number goes up. Actual throughput doesn't change.
• It hides variability. A team with "40 points per sprint" might deliver everything in the first week and coast, or might scramble to finish on the last day. Velocity can't tell you which.
• It says nothing about flow. Two teams with identical velocity can have wildly different cycle times, meaning one delivers continuously while the other delivers in batches at the end of the sprint.

Cycle time addresses all of these. It's comparable across teams (days are days). It can't be gamed without actually improving the process. It reveals variability directly. And it measures flow, which is what customers and stakeholders actually care about.

Reading a Cycle Time Chart

A cycle time chart plots each completed work item as a dot, with the completion date on the x-axis and the cycle time (in days) on the y-axis.

What a healthy chart looks like:

• Most dots clustered in a tight band (consistent cycle time)
• Few outliers above the cluster
• A stable or downward trend over time

What a troubled chart looks like:

• Wide scatter (unpredictable delivery)
• Frequent outliers (items that get stuck)
• An upward trend (the system is degrading)

The power of the chart is in the conversation it creates. When a dot is an outlier, the team asks: what happened with that item? Was it blocked? Was it too large? Did we discover unexpected complexity? Each outlier is a learning opportunity.

Understanding Spectral Analysis

The spectral analysis chart (included in the template) shows the frequency distribution of cycle times. Think of it as answering: "How often do we deliver items within X days?"

This is the chart you show leadership when they ask "when will this be done?" Instead of a single-point estimate, you can say: "Based on our cycle time data, there's an 85% probability we'll deliver this in 8 days or fewer."

That's predictability built on data, not optimism.

How to Use the Template

The Excel template generates both charts from your raw data. Here's how to get started:

1. Collect your data. For each completed work item, record the start date and completion date. If you use Jira, Azure DevOps, or a physical board, this data likely already exists.

2. Enter it in the template. The template calculates cycle time automatically from the start and completion dates.

3. Generate the charts. The cycle time trend chart and spectral analysis chart update automatically as you add data.

4. Review weekly. The value isn't in the chart itself. It's in the team conversation about what the chart reveals.

What Cycle Time Data Tells You About Your System

Once you have a few weeks of data, patterns emerge:

High average cycle time (items take too long):

• Work items are too large and need decomposition
• Too much work in progress is creating context-switching overhead
• External dependencies are blocking flow

High variability (unpredictable cycle time):

• Inconsistent work item sizing
• Unplanned work is disrupting flow
• Quality issues are causing rework

Increasing trend (getting slower over time):

• Technical debt is accumulating
• Team capacity is being eroded by support or operational work
• The process has degraded and needs attention

Each of these patterns points to a specific intervention. That's what makes cycle time actionable in a way velocity is not. Velocity tells you "we delivered less." Cycle time tells you why.

Connecting Cycle Time to Business Outcomes

Cycle time is not a metric for its own sake. It's a leading indicator for three of the 9 Business Outcomes:

• Speed: Shorter cycle time means faster delivery to customers
• Predictability: Consistent cycle time means reliable forecasting
• Quality: Decreasing cycle time with stable defect rates means the team is improving efficiency without cutting corners

When leadership asks "are we getting better?", cycle time provides a concrete, honest answer. It's one of the metrics we recommend in the Path to Agility framework because it connects team-level performance to organization-level outcomes.

Beyond the Spreadsheet

The Excel template is a great starting point, especially for teams that don't have tooling in place yet. As your practice matures, you'll likely want to pull cycle time data directly from your work management tool (Jira, Azure DevOps, etc.) for real-time visibility.

The Path to Agility Navigator integrates flow metrics alongside capability assessments, so leadership can see both how fast teams are delivering and what capabilities are driving that performance. But you don't need a platform to start. A spreadsheet and a weekly conversation will get you further than most organizations realize.

If you want to understand where cycle time fits into your broader transformation picture, take the Organizational Health Check. It assesses your organization across 9 Business Outcomes and identifies whether Speed, Predictability, or another dimension is the one that needs attention first.