What is velocity, and how do you measure it in Metabase?

Velocity is the number of story points (or items) a team completes per sprint. It is the most used and most misused metric in agile delivery: genuinely useful for planning the next sprint and projecting a release burndown, and reliably corrupted the moment it becomes a target. Measure it in Metabase from sprint and issue data synced from Jira, Linear, or Azure DevOps.

What does velocity measure?

The team's demonstrated capacity, in its own units. Points encode a team's private calibration of effort and uncertainty, which makes velocity good at exactly one job — answering "how much should we commit next sprint?" — and bad at every job it gets drafted into:

• Planning signal — the rolling 3-sprint average is the commitment baseline, and remaining scope divided by it is the finish-line projection on the release burndown. This is the legitimate use.
• Not a cross-team comparison — points aren't standardized, so a leaderboard of velocities compares units, not output. Teams asked to compete on it simply re-price their points.
• Not a target — Goodhart's law applies with unusual force because the team both produces the number and defines its unit. "Increase velocity 20%" is satisfiable by estimating 20% higher, and eventually — under enough pressure — that's what happens, silently, and the planning value is gone.

For questions about whether delivery is actually getting better, use metrics with fixed units: cycle time and lead time measured in days, or task throughput in items. Velocity's companion number is the say-do ratio — committed points versus completed points — which catches chronic over-commitment without turning points into a performance score.

What data does it need?

• A sprints table (id, name, started_at, ended_at) and an issues table with sprint_id, story_points, status_category, and completed_at.
• A consistent completion rule: points count in the sprint where the issue finished, and carryover counts once, at completion.
• For say-do ratio: sprint membership at sprint start — from Jira's sprint scope history or a snapshot taken when the sprint opens. Current-state data can't distinguish committed work from mid-sprint additions, so without that history, report velocity alone and skip the ratio.

SQL patterns

SELECT
  s.name AS sprint,
  s.ended_at::date AS sprint_end,
  SUM(i.story_points) AS completed_points,
  ROUND(AVG(SUM(i.story_points)) OVER (
    ORDER BY s.ended_at
    ROWS BETWEEN 2 PRECEDING AND CURRENT ROW
  ), 1) AS rolling_3_sprint_avg
FROM sprints s
JOIN issues i ON i.sprint_id = s.id
WHERE i.status_category = 'done'
  AND i.completed_at <= s.ended_at
GROUP BY s.id, s.name, s.ended_at
ORDER BY s.ended_at;

SELECT
  s.name AS sprint,
  SUM(si.story_points) FILTER (WHERE si.in_sprint_at_start)
    AS committed_points,
  SUM(si.story_points) FILTER (
    WHERE si.in_sprint_at_start AND si.completed_in_sprint
  ) AS completed_committed_points,
  ROUND(
    100.0 * SUM(si.story_points) FILTER (
      WHERE si.in_sprint_at_start AND si.completed_in_sprint
    ) / NULLIF(
      SUM(si.story_points) FILTER (WHERE si.in_sprint_at_start), 0
    ), 1
  ) AS say_do_ratio_pct
FROM sprint_issues si
JOIN sprints s ON s.id = si.sprint_id
GROUP BY s.id, s.name
ORDER BY MAX(s.ended_at) DESC
LIMIT 12;

Pitfalls

Where this metric applies

• Jira + Metabase — sprint points with scope history for say-do
• Linear + Metabase — cycle estimates and completed points
• Azure DevOps + Metabase — iteration effort and completed work
• Shortcut + Metabase — iteration points per story

Related

Metrics

Dashboards

FAQ