Compare team cycle time: finding out who's actually slow, and why
Live only on the Comparison view — select two or more boards and it plots one cycle-time line per board, plus a scorecard with each team's median cycle time and total items delivered. It exists for the moment a stakeholder says "Team B feels slower than Team A" and you need an actual number instead of a vibe.
| Board | Median cycle (p50) | Delivered |
|---|---|---|
| Payments | 2.8d | 64 |
| Growth | 4.1d | 51 |
| Platform | 9.6d | 22 |
Cycle time in days, three boards, plus the flow scorecard.
Delivered volume greyed — this board set mixes Jira and Azure DevOps, so item counts aren't apples-to-apples.
What it measures, and where the data comes from
Cycle time is the median days from an item's first "in progress" transition to done, plotted per board, per week. The scorecard restates it as one median-days number per team over the whole window, and adds a second column: total items delivered.
- Jira — issues, in-progress-to-done transition timestamps, per project.
- Azure DevOps — work items, same transition window, from connected projects.
Lower cycle time is better — it means work moves from "started" to "shipped" faster. The delivered-items column is a straight count, and Jira and ADO don't slice work into tickets the same way, so whenever the compared boards mix providers, that column greys out. Read the cycle-time line and the median column with confidence regardless of provider mix; treat the delivered count as directional only when providers match.
How to read it
Rank the lines, not the raw days. Whichever board's cycle-time line sits highest is the team taking the longest from start to finish — and that's your next question, not your next conclusion. A high line doesn't mean a slow team; it usually means a blocked one.
Watch shape as much as height. A line climbing steadily while the others hold flat says something changed specifically for that team — a new dependency, a departed reviewer, a process that got heavier. A line that's simply always been higher than the rest is a different, more structural conversation.
What it tells you over time
This is the widget for the "should we invest in fixing Team X's process" decision. If one board's cycle time has sat meaningfully above its peers for a full quarter, that's not noise — it's the board to prioritize for a flow-improvement push, whether that's WIP limits, unblocking a dependency, or headcount.
Example situations
1. Stakeholders say Team B feels slower — now there's a number
Platform's cycle time roughly 3.5x Payments', holding for eight weeks.
What you're seeing: Payments' cycle time sits low and flat around 3 days. Platform's sits high and flat around 10 — not climbing, just consistently, structurally slower, week after week for two months.
How to react: a flat-but-high line is different from a climbing one. This isn't a recent regression — it's baseline behavior. Go find what's structurally different: is Platform's work inherently larger scope, does it sit behind more external dependencies, is WIP per person higher? Don't assume it's effort.
2. One board's cycle time starts climbing while its peers hold flat
Growth's line climbing for four weeks against a flat Payments baseline.
What you're seeing: Growth used to track close to Payments. Over the last four weeks its line has climbed sharply while Payments barely moved — this is team-specific, not a market-wide slowdown.
How to react: because the other boards are flat, you can rule out anything company-wide — a holiday, a platform outage, a hiring freeze. Look for what changed for Growth specifically: did someone leave the team, did scope change, did a new dependency get introduced four to five weeks back?
Frequently asked
- How do I compare cycle time between teams?
- The Comparison view plots one cycle-time line per selected board plus a scorecard showing each team's median cycle time and total delivered items, so a claim that one team is slower than another can be checked against a number.
- Is a higher cycle time always worse?
- No. Teams working on different problem shapes have legitimately different cycle times. The useful comparison is each team against its own trend, with the cross-team view used to find outliers worth asking about.
- Why does delivered volume grey out on some comparisons?
- When the selected boards mix providers, delivered volume is not comparable across them, so it is suppressed rather than shown misleadingly. Cycle time remains valid.
Related widgets
- Compare: Delivery — pairs with this to separate "slow" from "not delivering."
- Compare: Review Quality — checks whether thin review discipline is the hidden driver of a high cycle-time board.
- Flow Throughput / Cycle Time — the single-board version of this same metric.
- Period Comparison — the single-board cousin of this widget: one board across two time periods, instead of many boards over one window.
- Back to the widget reference.
Last updated