Velocity: What It Is and Why It Matters

What it measures

Velocity is a count of completed work: how many items a team finished in a given period, day by day or week by week. It sounds close to throughput, and in flow-based thinking it largely is the same idea — the difference from older, story-point-based "velocity" is that this version counts finished items, not estimated effort, so it can't be inflated by re-estimating the same backlog bigger.

Why it matters

Velocity is the number that turns "the team feels busy" into "the team is actually finishing things." Busy and productive aren't the same — a team can have high WIP, long hours and constant context-switching while shipping very little, because attention is spread too thin across unfinished work. Velocity is the counterweight: it only credits work that crossed the finish line, which is what a roadmap, a stakeholder, or a customer actually experiences.

It's also the number that makes other flow metrics actionable together, not in isolation. A rising WIP with flat velocity is a specific, useful signal — it means more is being started than finished, and cycle time is about to get worse even before it shows up in the average. Watched alone, none of cycle time, WIP or velocity tells the full story; watched together, they explain each other.

How to calculate it

Count items with a completion timestamp inside the period, and plot the count per day or per week. The one decision that changes the number meaningfully: what counts as "completed" — the cleanest definition is the first time an item reaches a status your team has classified as done, not the last time (an item that gets reopened and redone shouldn't get counted twice just because it crossed the finish line more than once).

How to interpret the number

Unlike DORA's four metrics, flow metrics don't have a widely published "elite vs. typical" industry benchmark — team size, work item granularity and what counts as "one item" vary too much between teams for a universal number to mean much. The useful comparison is a team against its own recent history, not against another team's velocity: a steady or improving trend over several weeks matters more than the absolute count on any single week, and a sudden drop is worth investigating (fewer people, bigger items, or work getting stuck earlier in the pipeline) before assuming it's a motivation problem.

A common trap

Comparing velocity across teams almost always produces the wrong conclusion, because "one item" means something different on every board — a team that splits work into small tickets will show a higher velocity than one that files fewer, larger ones, without actually shipping more. Velocity is a trend metric for a single team over time, not a leaderboard between teams.

How moasy.tech computes it

moasy.tech recalculates velocity automatically from the completion history already synced from Jira and Linear — read-only, no manual counting, with a day-by-day breakdown shown next to WIP and cycle time so the three tell a single, connected story instead of three separate charts.

See the other flow metrics in the full guide, or the complete implementation on the Flow Metrics feature page.

Illustrative data, for demonstration purposes only.

Questions about velocity