Jira Team Velocity

Velocity is the most-used number in Jira planning — and the easiest to misread. "We do about 30 points a sprint, so the 120 points left is four sprints" feels rigorous, but it plans off an average that hides the trend, the spread, and who is actually doing the delivering. Reading team velocity in Jira honestly means looking at all three — and then treating velocity as an input to the forecast, not the forecast itself.

What team velocity actually tells you

Velocity is how much work your team completed per sprint — story points, or hours if you estimate in time. Jira gives you the raw number; the planning value is in how you read it:

• The trend, not the last number. Is velocity improving, stable, or declining over the last several sprints? A single hot sprint isn't a new baseline — and a slow decline is a schedule risk long before it's a missed date.
• The spread, not the average. "30 points a sprint" might be a tidy 28, 30, 31 — or a wild 12, 30, 48. Same average, completely different risk. A steady team can be planned further out; a volatile one needs a range, not a single number.

Project Commander charts your velocity history sprint by sprint with its trend and rolling average, so you plan off what the number is actually doing — not off one flattering sprint.

Velocity by team member — where the team number hides the risk

A team velocity of 30 can conceal a fragile reality: two people carrying most of it, a third blocked every sprint. The team number looks stable while the distribution underneath isn't — lose one person and "30" was never real. Tracking velocity per person as well as per team shows how much of your throughput depends on whom, and where the single points of failure are, before a resignation letter finds them for you. Project Commander tracks both.

Velocity is not capacity

This is the misread that sinks plans. Velocity is output — what the team delivered when everyone was there. Capacity is availability — what they can do next sprint given who's actually around. Two people on leave, a new hire ramping up, someone pulled onto another project: none of it shows in the velocity number, all of it changes what next sprint can deliver. Project Commander keeps the two separate and uses both — your velocity history as evidence of pace, your real per-person capacity as the constraint — and weighs the remaining work against them through your release date. (The capacity half of that story has its own page: Jira capacity planning.)

The effectiveness factor: committed vs. delivered

A team that reliably finishes 80% of its sprint commitment should be planned at 80%, not 100%. Project Commander measures this from your own sprints — delivered versus committed — so the plan reflects how your team actually finishes, not how the planning meeting hoped it would.

From velocity to a forecast you can defend

On its own, velocity is a rear-view mirror. Combined with real capacity and dependencies, it becomes a forecast: Project Commander uses your velocity as one input to a capacity-aware delivery forecast — a projected finish date you can put in front of stakeholders, with the evidence behind it one click away. When the trend declines, you see it in the forecast before you feel it in the release.

The honest read of velocity is three questions: which way is it trending, how consistent is it, and who is actually producing it? Answer those — and plan against real capacity, not last quarter's output — and velocity stops flattering the plan and starts informing it.

Related reading: How to read team velocity without fooling yourself · Jira capacity planning · All Project Commander features