What the number rolled on velocity tracker means.

Short answer: Tracker velocity is the average story points the team has accepted per sprint, computed over the last three sprints. The rolling-3 average smooths out one-bad-sprint noise without lagging the trend. Only accepted stories count — not stories in progress, not tasks, not bugs. The number's job is forecasting; if you're using it for anything else, you're misusing it.

Tracker velocity shows how many story points the team has finished and accepted every sprint on average, calculated over the last three sprints. That’s it. Average number of story points in three sprints divided by the number of accepted stories.

Why does it matter: velocity is the forecast tool for the team. If a backlog with point estimates and a rolling velocity is provided, an answer to “when will we finish X?” is feasible. Without it, you assume. If you aren't using rolling average of only accepted stories from the last 3 sprints, then your number has a problem. Either it’s too noisy (single-sprint), too lagged (lifetime average) or padded with non-user-value work (tasks counted in). For the long view on why velocity matters as a forecast tool, the framing has not changed in fifteen years.

This guide will walk you through the calculations, why a rolling-3 window is the window to use, what counts and what doesn't, common misuses, and a strong opinion that beats most modern variants. Scrum masters, anchors, and engineering leaders who want their forecasts to carry some weight.

How velocity is calculated

For every sprint, we sum up the points for stories that the team accepted in that sprint. The average of the last three of those sums is the velocity.

A practical example. The last 6 sprints of the team accepted a total of 18, 24, 22, 20, 26, and 23 points. The velocity calculated for a rolling 3 is equal to (20 + 26 + 23)/3 which gives 23 points. The team’s forecasting budget for the next sprint is 23 points, plus or minus a projection of the distribution.

This is the formula Pivotal Tracker popularized, and the underlying logic is the same one Martin Fowler describes in his note on XP velocity — a running average of yesterday’s weather, used for planning, never as a goal. Pivotal Tracker has shut down, but the calculation is the right one and its successors carry this over.

Why rolling-3 beats every other variant

The three common alternatives, each worse than rolling-3:.

• Single-sprint velocity — uses last sprint's points as the forecast. Sensitive to one-off events: a holiday week, a sick day, a particularly easy sprint. The forecast bounces sprint-to-sprint and stakeholders stop trusting it.
• Lifetime average velocity — uses every sprint the team has ever run. Lags reality: if the team got faster six months ago, the average still reflects the slow period. The forecast is wrong in the direction the team has improved.
• Long-rolling (5, 8, 10) — smooths more, lags more. Good for very stable teams; bad for teams whose composition or product is changing.

A rolling average of three sprints is the perfect number. It filters out the static noise of individual bad sprints, while also having enough sensitivity to catch real changes within a quarter. The metric can be easily hand-recomputed in five seconds; this keeps it tangible.

The question of exact window size has been over-thought. Rolling-3 is the default option; rolling-4 or rolling-5 is also fine with reasons. The more impactful choices are the definition of accepted and how you onboard new team members   those truly move the needle. A healthier approach to estimating velocity starts with that definition long before it picks a window size.

What counts toward velocity

A story that was accepted by the PM in this sprint is the strict definition. That's all.

What is excluded

• Stories started but not accepted. Carryover gets the points credited in the sprint they're accepted in, not the sprint they were worked in. This is the right answer even though it feels harsh — half-done work isn't user value, and partial credit gives the team an incentive to declare partial completion just to look productive.
• Bugs. The original story that produced the bug was already pointed when accepted. Re-pointing the bug double-counts.
• Tasks. Engineering work that doesn't produce user-visible behaviour isn't user value, and velocity is meant to forecast user value shipped. (See why bugs and chores don’t get estimated for the full argument.)
• Chores. Internal team work — running an upgrade, attending a conference, on-call rotations.
• Stories the PM rejected at acceptance. If the story shipped but didn't meet the definition of done, it's not accepted yet. Points get credited when it does.

We have strong beliefs. We see many teams who have such tracker configuration that allows them to point any issue type. Many teams point their “task” and “bug” issue types so that their velocity looks healthy. This figure represents not velocity anymore but “story-equivalent throughput”, which conveys engineering activity at work but not user value.

The pattern we’re describing can be seen in action across most Tracker-style tools – by default only stories accept points, and bugs/tasks/chores are tracked but unpointed. It is more important to enforce structure than to enforce discipline, as discipline drifts, but structure does not. The Atlassian field guide to agile estimation lands in the same place: estimate user-value stories, leave engineering chores out of the velocity number.

The most common misuse

After working with enough teams, the anti-pattern we see most is velocity as a performance metric.

Sypmtoms

• The team's velocity is on a dashboard somebody is judged against.
• The PM points stories slightly higher to "match team capacity".
• The team carries over fewer stories so the points look "complete".
• Velocity goes up. Real output is flat or slightly down.

Goodhart's Law states that when a measure becomes a target, it ceases to be a good measure. Velocity can be used to forecast. As soon as a number is judged on some dimension, the team will start producing the number rather than the work the number was meant to forecast. The argument that velocity is not the goal is roughly fifteen years old at this point, and teams still rediscover it every quarter.

To resolve this, velocity should not be included in performance evaluations and stakeholder updates that are not team-specific. Forecasts are internal; output is what stakeholders should see.

Another Misuse: Comparison of Velocity Across Teams Is Team A faster than Team B in a scenario where Team A has velocity 30 and Team B has velocity 18? Most likely teams A and B point a story differently. Within a team, story points serve as a measure of relativity, not one of absoluteness. The only thing that should be compared is a single team’s velocity over time.

What velocity is not

Velocity Is Not

• Speed. Faster cycle times produce more velocity, but more velocity doesn't mean faster cycle times. They're correlated, not equivalent.
• Productivity. Acceptance is binary; engineering effort isn't. A team can ship a small story with massive engineering effort behind the scenes and get the same velocity credit as a different team shipping an obvious one-line change. Velocity is a measure of pace, not productivity, and treating it as the latter is the cleanest way to ruin both.
• A commitment. Velocity is a forecast based on historical data. The team doesn't promise to hit it — they plan against it and adjust mid-sprint when reality diverges.
• A target. Targets cause gaming (see above). Velocity is a measurement, not a goal.
• Comparable across teams. Within-team trend, yes. Between-team comparison, no.

The math shows that when stories are smaller, your cycle times drop from days to hours, your teams reach users up to 14 times faster and your velocity becomes more stable, since the variance per story is smaller.  Large stories result in significant fluctuations in velocity, while smaller stories yield consistent outcomes — the practical mechanics are covered in choosing the best slice for your story. The mechanism is statistical and not motivational.

When velocity breaks down

The genuine scenarios where the metric proves ineffective.

• Team < 4 people. Too few stories per sprint for the average to mean anything. Variance dominates the signal.
• New team. Three sprints minimum, ideally six, before the number is stable enough to forecast against. Don't act on velocity for the first quarter. The Scrum Guide is explicit that empirical process control needs enough data to be empirical in the first place.
• Major team change. New senior engineer, three engineers leaving, full-team rotation — restart the velocity baseline. The old number doesn't apply.
• Major product change. New domain, new codebase, new platform — same as a new team. Reset.
• Pure operations / support team. No story-shaped work. Velocity doesn't apply; use throughput metrics (issues closed per week) instead.

If you’re not a team or a leadership, then track only velocity and do forecasting from velocity. But don’t put velocity on public dashboards.

When NOT to use story points (and therefore not velocity)

A genuine viewpoint is that not all teams need story points. Certain teams deliver higher quality results without grooming.

The story counts rationale is that when teams generate small, similarly-sized stories, the resulting distribution of story counts is predictable enough to plan against. Plus, it avoids the overhead of estimation. The argument in favour of points: stories are never the same size, and points take that variation.

Selection made by the team. If your team aggressively splits stories and the majority of them end around the same size, story counts work. Points are the correct tool when your team has wider story-size distribution. Changing the unit of measure is fine; it will not affect the velocity calculations.

If you aren’t using either approach and just guessing what fits, that’s gambling, not forecasting. The deeper case for predictability over raw velocity sits on the same logic — the goal is a stable, trustworthy forecast, not a bigger number on a slide.

Frequently asked

What is tracker velocity?

It is the average of all story points a team has accepted over the last three sprints (rolling-3). It’s literally the team’s forecast tool   how much work can the team plan into the next sprint with reasonable confidence.

How do you calculate velocity?

In every one of the last three iterations, how many story points were ‘accepted’? Sum them and divide by three. The main metric is accepted work. All work that is started but not accepted does not count. Tasks, bugs and chores do not count either.

Why use rolling-3 instead of last sprint or lifetime average?

Last sprint data is too noisy because one bad sprint kills the forecast. Meanwhile, lifetime average lags because it is slow to react to real changes in the team. Rolling-3 filters out short term noise but keep mid term responsiveness. It's the just-right window.

Should tasks and bugs count toward velocity?

No. The velocity should forecast the user value shipped. In a healthy setup tasks and bugs are tracked but not pointed. Overestimating software benefits without added user value will create an inaccurate software impact forecast.

Can I compare velocity across teams?

No. Story points are a unit of estimation that is relative to the team. Team A’s “5” is Team B’s “4". The velocity trend of a singular team is the only valid comparison.

What if my team's velocity is dropping?

Examine, Don’t Respond. We see coiling possibilities of different kinds: new team members ramping up, technical debt blocking progress, story sizes growing larger, PM pointing higher agreeing to control scope. We must view the drop as a signal to investigate rather than a number to push back up.

Is velocity a commitment?

No. This is a projection based on history. The team will use that date to plan its next sprint, but won't commit to it. When velocity is treated as a commitment, you turn it into a target. Once it’s a target, the metric stops meaning anything.

How long until velocity is reliable?

The requirement is a minimum of three sprints (the three samples need to be averaged) six is ideal (the variance has settled). When a team first begins operating, acting on velocity in the first quarter produces forecasts that are mostly noise.

Still stuck

The discipline involves using tracker velocity calculated with rolling three, accepted stories only, excluding public dashboards, and for forecasting only. The teams often have disagreement on velocity; this is either about counting tasks (no) or comparing teams (no). The calculation itself is the easy part.

.

LiteTracker is the tool to use if you want the right calculation by default   rolling-3, accepted-stories-only, and points only on stories. If you have fewer than four engineers or you’ve shipped fewer than three sprints, the number won’t mean anything yet   wait until you’ve got the samples  (0)

Forecasts should not be commitments and it should be internal not external.