Lead Time, Cycle Time & Throughput – a simple guide with one example

One board, one ticket – three views on the same flow

In this article, we'll look at the three base metrics using a minimal example.

• Your team works on a Kanban board with columns: Backlog → Selected → In Progress → Review → Done
• On Monday morning, a new ticket enters the Backlog
• On Wednesday, the team selects it for the next sprint (Selected)
• On Thursday, work starts (In Progress)
• Next Tuesday, the ticket is reviewed and merged (Review → Done)

Now we can define the three metrics – Cycle Time, Lead Time and Throughput – just by looking at this one ticket and the board around it.

Lead Time – from “I want this” to “it’s live”

Lead Time answers: How long does a request take from first appearance until it is delivered?

In our example:

• The ticket appears in Backlog on Monday (request created)
• It reaches Done on Tuesday of the following week (request delivered)

If you count calendar days, that’s 8 days of Lead Time. Lead Time is what business stakeholders and product folks usually care about most – it tells them how long they typically wait from idea to outcome.

Cycle Time – from "We started" to "We finished"

Cycle Time answers: How long is the ticket actively in progress?

In our example:

• The ticket reaches the Commitment column on Thursday (e.g. when it leaves Backlog and is pulled into In Progress)
• It reaches Done on Tuesday of the following week

That gives you 5 days of Cycle Time. Cycle Time is the part of Lead Time that your delivery team directly controls – it reflects how smoothly work flows once it has been pulled into the system.

Visualizing Cycle Time within Lead TimeFigure 1: Lead Time (top) from Backlog to Done, and Cycle Time (bottom) from Commitment column to Done column. Both end at Done, but Cycle Time starts later when the team actually commits to the work.

Figure 1 highlights how the Commitment column defines the start of Cycle Time, while the Done column is the shared end point for both Lead Time and Cycle Time. Here you can see the relationship:

• Lead Time includes everything from “requested” to “delivered” (Backlog → Done).
• Cycle Time focuses on the committed work from Commitment column to Done column.

If Lead Time is long but Cycle Time is relatively short, your problem is often earlier (waiting in Backlog) or later in the process (stuck in Review / QA depending on the teams definition of done).

Throughput – how many items finish per time period

Throughput answers: How many tickets do we finish per week (or per day, per month, …)?

In our example week:

• Let’s say 6 other tickets also reach Done between Monday and Sunday
• Together with our example ticket, that’s 7 tickets finished in this week

So your Throughput for the week is 7 tickets/week. Throughput is like the speedometer of your system – it tells you how much work actually leaves the system. That's the basis for realistic forecasting.

Throughput visualizationFigure 2: Throughput chart showing the number of tickets completed each day. Each bar represents tickets that reached Done on that specific day.

Figure 2 shows how often the Done column is reached over time, turning the movement of tickets into a measurable throughput signal. Consistent heights indicate stable delivery, while high variation suggests process instability or inconsistent work patterns.

Wrapping up the metrics for the example

With this simple example, we can already see how the three metrics hang together:

• Lead Time (8 days) = waiting + active work + finishing touches
• Cycle Time (5 days) = just the active work until Done
• Throughput (7 tickets/week) = how many tickets reach Done in the same period

They are not competing metrics – they are three perspectives on the same flow:

• Lead Time speaks the customer language (“How long do I wait?”).
• Cycle Time speaks the delivery language (“How long do we need to finish once we start?”).
• Throughput speaks the systems language (“How much can we reliably ship per time unit?”).

What to do when the numbers start to wobble

Real teams don’t have perfectly stable metrics. That’s fine – actually, the variation is the interesting part. Here are some typical patterns you’ll see in flow diagrams and what they usually mean:

• Lead Time is jumping up and down, Cycle Time is stable: your bottleneck is probably before work starts (prioritization, waiting for input) or after dev (review, deployment).
• Cycle Time is highly variable: your “In Progress” work is inconsistent – too many different ticket sizes, context switching, or WIP limits not enforced.
• Throughput is all over the place: your system has no stable rhythm yet – teams might be starting too much and finishing too little.

Instead of panicking about outliers, use them as starting points for conversations:

• “What was different in this ticket?”
• “Why did this week’s throughput drop?”
• “Which column did this work item stay in for the longest?”

That’s where improvement lives.

We've only scratched the surface here. In later posts, we'll dig deeper into how Cumulative Flow Diagrams (CFDs) and Monte Carlo simulations build on these three base metrics to provide richer forecasts and capacity insights.

How flowban helps with these three metrics

flowban connects directly to your GitHub Projects and calculates the three base metrics for you:

• Lead Time: from first appearance of an issue in your board until it hits your Done column.
• Cycle Time: from commitment (e.g. when an item leaves Backlog or enters In Progress) until Done.
• Throughput: how many issues reach Done per day, week or month.

With flowban you gain access to diagrams like the ones shown above, customized to your workflow and board setup – so that you can:

• Spot bottlenecks early by seeing where work piles up across your board.
• Stabilize delivery by making Lead Time, Cycle Time, and Throughput visible and comparable over time.
• Explain delivery behavior with data instead of opinions in stakeholder conversations.
• Prepare for advanced analysis and forecasting like CFDs and Monte Carlo simulations without extra scripts or spreadsheets.

All three metrics stay tied to the same reality: issues moving across your GitHub board.