The Team Lead Handbook · Running the Team's Work
Flow Metrics: Cycle Time and Throughput
Measure how work flows through the team — cycle time, throughput, WIP and work-item age — from a ticket log, and use them to find bottlenecks instead of judging people.
Scenario
Example team: the checkout team's manager asks for "a productivity metric". Someone proposes story points per engineer. The team lead worries it will be gamed and make the team worse.
What you see on the team
- Requests for individual productivity numbers.
- Velocity charts that move with estimation habits, not delivery.
- No shared data about where work waits.
- Arguments about whether the team is "slow".
The common mistake
Measuring individual activity or estimates (points, commits, tickets per person) instead of how work flows through the team.
Why it happens
Individual metrics are easy to collect and feel objective. But they're easy to game, they discourage helping others (reviews and pairing don't count), and they don't show where work is stuck. Flow metrics measure the system — and the system is what a team lead can change. The Kanban Guide defines a small set of flow measures, including work in progress, throughput, work item age and cycle time.
The playbook
Four flow metrics, computed from your ticket history:
| Metric | Meaning | Use it to ask |
|---|---|---|
| Throughput | Items finished per week | Are we delivering steadily? |
| Cycle time | Start to done, per item (look at 50th and 85th percentile) | How long does a typical item take? |
| WIP | Items started but not finished | Are we starting too much? |
| Work item age | How long current items have been in progress | Which items are stuck now? |
from datetime import date
import statistics
# (ticket, started, finished or None) - example export from the issue tracker
log = [
("CHK-101", date(2026, 9, 1), date(2026, 9, 3)), ("CHK-102", date(2026, 9, 1), date(2026, 9, 12)),
("CHK-103", date(2026, 9, 2), date(2026, 9, 4)), ("CHK-104", date(2026, 9, 3), date(2026, 9, 18)),
("CHK-105", date(2026, 9, 7), date(2026, 9, 9)), ("CHK-106", date(2026, 9, 8), date(2026, 9, 10)),
("CHK-107", date(2026, 9, 9), date(2026, 9, 25)), ("CHK-108", date(2026, 9, 14), date(2026, 9, 16)),
("CHK-109", date(2026, 9, 15), date(2026, 9, 17)), ("CHK-110", date(2026, 9, 21), None),
("CHK-111", date(2026, 9, 22), date(2026, 9, 24)), ("CHK-112", date(2026, 9, 24), None),
]
today = date(2026, 9, 30)
done = [(t, s, f) for t, s, f in log if f]
cycle = sorted((f - s).days for _, s, f in done)
p85 = cycle[int(len(cycle) * 0.85) - 1]
print(f"throughput: {len(done)} items in 4 weeks ({len(done) / 4:.1f}/week)")
print(f"cycle time: median {statistics.median(cycle)} days, 85th percentile {p85} days")
print(f"WIP today: {sum(1 for *_, f in log if f is None)} items")
for t, s, f in log:
if f is None:
print(f" age of {t}: {(today - s).days} days")
slow = [t for t, s, f in done if (f - s).days > p85 - 1]
print(f"items at or above the 85th percentile: {', '.join(slow)} -> look at why they waited")
Output
throughput: 10 items in 4 weeks (2.5/week) cycle time: median 2.0 days, 85th percentile 11 days WIP today: 2 items age of CHK-110: 9 days age of CHK-112: 6 days items at or above the 85th percentile: CHK-102, CHK-104, CHK-107 -> look at why they waited
Use the 85th percentile to set expectations ("85% of items finish within N days") and to spot outliers worth discussing.
Look at the outliers in retros: what made those items slow — reviews, dependencies, unclear requirements?
Never rank individuals with these numbers; they describe the team's system.
What to say
To a manager asking for individual productivity:
"Individual points or ticket counts would push people to stop reviewing and pairing. I'd rather report how work flows: throughput, cycle time and what's stuck. Last month 85% of items finished within 11 days; the three slowest all waited on the risk team — that's what we're fixing."
Trade-offs
- Ticket data is messy; agree what "started" and "done" mean before measuring.
- Different item sizes blur the numbers; slicing work smaller makes them more meaningful.
- Metrics can still be gamed (splitting tickets artificially); use them for questions, not targets.
Signals it's working
- The team reviews flow metrics monthly and discusses outliers.
- 85th-percentile cycle time trends down.
- Stuck items (high age) are noticed in days, not weeks.
- Nobody asks for individual productivity rankings any more.
Key points
- Measure the flow of work: throughput, cycle time, WIP and work item age.
- Use percentiles (50th and 85th), and investigate outliers in retros.
- Flow metrics describe the system — never rank individuals with them.
- Define "started" and "done" clearly before measuring.
Practice questions
Your manager asks for story points per engineer as a productivity metric. What do you propose instead, and why?
Answer
Team flow metrics — throughput, cycle time percentiles, WIP and work item age — because individual points are easily gamed, discourage reviewing and pairing, and don't show where work is stuck.
Why use the 85th percentile of cycle time rather than the average?
Answer
Cycle times are skewed by a few slow items; the 85th percentile gives a realistic expectation ('85% of items finish within N days') and highlights outliers worth investigating.
What is 'work item age' and why is it useful?
Answer
How long an item currently in progress has been in progress. It flags stuck work now, before it shows up in finished-item cycle times.
Open in the app to mark lessons complete, take notes and track your progress.