Deploy free

Throughput and cycle time: what it means when the bars and the line disagree

This widget puts two numbers on one chart on purpose: bars for how much shipped each week, a line for how long each of those items took from creation to done. Throughput and cycle time move together when things are healthy and split apart the moment they aren't — which is the entire reason to look at them side by side instead of one at a time.

deckgauge · Board · Intelligence

In the product this is one composed chart, bars and line together — split into two blocks here for legibility.

Six weeks: bars rising, cycle-time line easing down alongside them.

What it measures, and where the data comes from

Bars are a plain weekly count: how many Jira and Azure DevOps items were marked done that week. The line is the median (p50) number of days from an item's creation to its done transition, for that same week's cohort of deliveries — median so one ancient outlier can't tilt the whole line.

That outlier problem is handled explicitly, not left to hope. Every item has a configurable max-age (90 days by default); anything older than that gets excluded from the week's median and the week gets marked with a hollow point on the line instead of a solid one. Without this, a single quarter-old ticket closed alongside this week's normal work would drag the median wildly, and you'd read a fake trend off it.

Two sources, one chartJira and ADO items both count toward the bars and the median. If only one of your trackers has clean "created" and "done" timestamps, the cycle-time line will be noisier for boards mixing both — check the data-source split before reading too much into a single spike.

How to read it

Look at the two series as a pair, not separately. Rising bars with a falling (or flat) line is the combination you want — more gets delivered, and it isn't taking longer to do it. That's the shape in the mockup above, and it's rarer in practice than it should be.

The hollow marker is not a decoration — it's a warning label. It means the week's median is computed from a smaller, filtered set of items, because the excluded ones were old enough to distort it. Read a flagged week's number as partial information, not a real result, until you know what got excluded and why.

What it tells you over time

A single week telling a bad story is close to always noise — a sprint boundary, a public holiday, someone on leave. What you're watching for is direction held across a run of weeks: bars trending down while the line trends up at the same time is two problems compounding, not one blip. And because the widget is explicit about which weeks are flagged, you can tell a genuine speed-up in the trend from a bulk cleanup that only looks like one.

Example situations

1. Bars falling, cycle time climbing — both at once

deckgauge · Flow: Throughput & Cycle Time

Six weeks: fewer items shipped each week, each one taking longer.

What you're seeing: the bars step down every single week while the line climbs every single week, in the same direction, at the same time. That's not "the team is a bit slower" — it's throughput and speed degrading together, which usually means the whole system has more in flight than it can move.

How to react: don't ask people to work faster on individual tickets — the pattern says the problem is systemic, not personal. Pull Work in Progress next; if WIP has been climbing across the same weeks, you've found the mechanism, not just the symptom.

Managerial playCut WIP before you do anything else — cap how much the team can have in flight at once and hold the cap even when it feels uncomfortable to say no to new starts. Then go find the actual bottleneck instead of guessing: pull the items still open and see where they're stuck — code review, a shared staging environment, one overloaded approver. Fix the one stage that's actually clogged rather than asking the whole team to generically "move faster," which fixes nothing and burns goodwill.

2. A hollow marker where the line looks great

deckgauge · Flow: Throughput & Cycle Time

Week 3 spikes on bars — and shows a hollow point on the line.

What you're seeing: week 3's bar towers over the rest, and its point on the cycle-time line is hollow and sitting at a suspiciously fast-looking low. That combination is the signature of a bulk historical close — someone (or an integration) closed out a batch of old tickets that week, inflating the count while getting excluded from the median for being over the max-age.

How to react: don't repeat "cycle time hit a new best" in a standup or a deck off this week alone. The hollow marker exists specifically so you don't. Read it as partial data until you know what got bulk-closed and why — a backlog-cleanup pass, a migration, a stale-ticket sweep — none of which reflect this week's actual delivery speed.

Managerial playConfirm the cause before quoting the number anywhere. If it's a deliberate grooming pass, say so explicitly next to the chart so nobody mistakes housekeeping for a process win. If bulk closes like this keep happening every few months, that's its own signal — a Backlog Age problem building up between cleanups, not a cycle-time story at all.

Frequently asked

What is the difference between throughput and cycle time?
Throughput is how much shipped in a week, shown as bars. Cycle time is how long each of those items took from creation to done, shown as an overlaid line. Volume and duration are different questions and this widget puts both on one chart.
What does it mean when the bars and the line disagree?
It is the signal worth watching. Throughput and cycle time move together when delivery is healthy; a week with high throughput and rising cycle time usually means a batch of long-running work landed at once rather than that flow improved.
Why is a week sometimes flagged?
A flagged week means the data for it is partial, not that delivery was fast. Treat flagged weeks as incomplete rather than as a genuine dip.

Related widgets

Last updated