The engineering velocity leaderboard: a ranking that isn't a scoreboard
Velocity Leaderboard ranks engineers by average days from a project's first "In Progress" move to its "Done" move, fastest at the top. It looks like a scoreboard. Treat it like one and you'll wreck the team it's supposed to help.
| Rank | Engineer | Avg days | Completed |
|---|---|---|---|
| 1 | Priya Nair | 2.1 | 14 |
| 2 | Marcus Webb | 2.6 | 11 |
| 3 | Sofia Ricci | 3.4 | 9 |
| 4 | Devon Blake | 4.0 | 8 |
| 5 | Ana Kowalski | 4.9 | 6 |
| 6 | Tomasz Górski | 6.3 | 5 |
Six engineers, 30-day window. Synthetic names.
What it measures, and where the data comes from
Every row is one engineer. The number under it is an average of individual project timings, not a single stopwatch — so the mechanics matter more than usual here.
- Start of the clock: the first time a project moved into an "In Progress"-style status. This can predate your selected window — an old project that finally lands this month still gets timed from when work actually began, not from when it happened to finish.
- End of the clock: the project's move into "Done", counted only if that move happened inside your selected range (7 / 14 / 30 days).
- Whose name it lands on: the project's assigned owner — a single name per project on this board, pulled straight off the board itself. This works whether the board is edited by hand or its statuses arrive via a synced Jira, GitHub, or Azure DevOps promotion; the widget only cares that a status change was recorded.
Each engineer's number is the average of every project they finished in the window. No source-specific legs to enumerate here — this is Deckgauge's own board history doing the counting, whatever fed the status changes in the first place.
How to read it
Read the Completed column before you read the Avg days column. An average is only as trustworthy as the sample behind it, and this widget will happily rank someone #1 off two finished tickets. The rank tells you an ordering; the completed count tells you whether to believe it.
Then look at the shape of the whole list, not just the top row. A tight cluster from top to bottom means the team ships at a roughly consistent pace — healthy, boring, good. A long tail stretching away from the pack is the more useful signal, and it's rarely about who's trying harder.
What it tells you over time
Imagine Tomasz lands the gnarly payments migration this month and a batch of quick config tickets the next — his rank will swing hard between those two windows, and neither swing is about how hard he worked. Project mix does that to this leaderboard constantly. The only movement worth a conversation is a name that keeps sliding down release after release, regardless of what they were handed each time.
Example situations
1. A wide gap between #1 and the bottom of the list
| Rank | Engineer | Avg days | Completed |
|---|---|---|---|
| 1 | Priya Nair | 1.8 | 16 |
| 2 | Marcus Webb | 2.4 | 12 |
| 3 | Sofia Ricci | 3.1 | 10 |
| 4 | Devon Blake | 5.5 | 7 |
| 5 | Ana Kowalski | 8.0 | 6 |
| 6 | Tomasz Górski | 11.2 | 5 |
1.8 days at the top, 11.2 at the bottom — same window, same board.
What you're seeing: the gap between #1 and #6 is more than 6x. That's a wide spread of throughput sitting on one team, one board, one time window.
How to react: the honest first hypothesis is not "Tomasz is slow." Check what Tomasz was actually assigned — a rewrite of the payments module and a typo fix don't belong on the same leaderboard, but this widget puts them there anyway. Ask about blockers before you ask about effort.
2. A blazing average built on two completions
| Rank | Engineer | Avg days | Completed |
|---|---|---|---|
| 1 | Ana Kowalski | 0.9 | 2 |
| 2 | Priya Nair | 2.3 | 13 |
| 3 | Marcus Webb | 2.9 | 10 |
| 4 | Sofia Ricci | 3.6 | 9 |
| 5 | Devon Blake | 4.2 | 8 |
0.9 days at #1 — on a sample of two.
What you're seeing: Ana's average looks untouchable next to a field of engineers finishing 8 to 13 projects in the same window. She also finished the fewest projects on the list, by a wide margin.
How to react: two data points don't make a trend, they make a coin flip that happened to land well. Two small, easy tickets will produce exactly this number, and so will one lucky fast one. Don't hold this row up as the standard for anyone else to hit.
Frequently asked
- What does the velocity leaderboard rank?
- Engineers by average days from a project's first move into In Progress to its move into Done, fastest at the top.
- Is it safe to use as a performance ranking?
- No, and treating it as one will damage the team it exists to help. Days-to-done depends heavily on the kind of work assigned, so a slower average often reflects harder problems rather than a slower engineer.
- What is a suspiciously fast average telling me?
- Often that someone is picking up small, well-defined items, or that tickets are being moved to Done in bulk. A very fast average deserves the same curiosity as a very slow one.
Related widgets
- Merge Frequency per Developer — a volume check that corroborates (or contradicts) a suspiciously fast average.
- Commits per Developer — raw activity, for when you want the input side of the story too.
- DORA Metrics — the team-level lead-time number this widget's per-engineer view sits underneath.
- Back to the widget reference.
Last updated