“Free Velocity Tracker Template (Fillable + Example)”

What does a velocity tracker template actually measure?

It measures finished work per sprint, expressed in the team’s own unit of estimate. A sprint that planned 44 points and delivered 39 has a velocity of 39, not 44, and not “39 plus the four that were nearly done.” The distinction sounds pedantic until a team starts counting partial credit and discovers that its forecasts are consistently 20% optimistic.

Velocity is not productivity. It is a calibration constant for one team’s estimation habits. Two teams can both deliver the same customer value while one reports 18 points and the other reports 60, because the first estimates in larger units. That is why cross-team velocity comparisons are meaningless, and why a manager who ranks teams by points is measuring the size of their units rather than the quality of their work.

The tracker exists to make three things visible that memory hides: whether commitment is realistic, whether carryover is structural or accidental, and whether a change in throughput is a trend or a single strange week. A spreadsheet with six rows answers those questions better than a dashboard with forty metrics, because the rows are comparable to each other.

What columns should a velocity tracker template include?

Five core columns plus one free-text note cover nearly every case. Add anything else only after you have used the core set for six sprints and found a specific gap.

Two optional columns are worth adding later. Committed items catches a subtle failure mode: a team that quietly splits stories into smaller pieces can raise its point total without delivering more. And a “scope added mid-sprint” column shows whether the gap between commitment and delivery came from optimism or from someone inserting work on day four.

Keep the table narrow enough to read on one screen. A tracker with nineteen columns gets updated for two sprints and then abandoned, which is worse than no tracker at all.

How do you calculate velocity from the tracker?

Velocity is the average of completed points across the sprints you consider representative. Use a rolling window of three sprints for tactical planning and six for quarterly forecasting, and state which window you used whenever you quote a number.

The formula is deliberately boring:

`velocity = sum(completed points) ÷ count(sprints)`

A second figure matters just as much — commitment reliability, or `completed ÷ committed` — because it tells you whether the average is stable or the product of wild swings. A team at 40 points with 95% reliability can plan confidently. A team at 40 points with 60% reliability has the same average and no ability to promise anything.

One worked example. Sprint log for a seven-person product team: 34, 41, 38, 45, 39, 43 completed points. The sum is 240, so the six-sprint average is 40 points. The three-sprint rolling average is (45 + 39 + 43) ÷ 3 = 42.3. Planning the next sprint at 40 is defensible; planning at 45 because the best sprint hit 45 is not.

Now the reliability side. Committed points across those same six sprints: 40, 40, 42, 46, 44, 44. Completed: 34, 41, 38, 45, 39, 43. Ratios: 85%, 102.5%, 90.5%, 97.8%, 88.6%, 97.7%. The average is about 93.7%, and the pattern shows a consistent two-to-four point shortfall rather than chaos. That is a fixable planning bias: the team adds about 10% optimism at planning time, and the tracker just made it visible.

What does a filled-in sprint log look like?

Here is the same team’s tracker, filled in as it would be at the end of sprint 24. The note column is doing real work: without it, the row is a number; with it, the row is a story someone can act on.

Read across the notes and a pattern appears that the numbers alone hide: three of the six shortfalls trace to review capacity, not to development capacity. The team keeps writing code faster than it can review it. The fix is not “estimate better”; it is to cap work in progress and protect review time. That is the kind of conclusion a tracker is supposed to produce, and it took one column and six rows.

Read the same table for cost and the picture sharpens. If the seven-person team costs $16,800 per week loaded, a two-week sprint costs $33,600. At 40 points, one point costs $840. The 6-point gap in sprint 19 was $5,040 of committed capacity that did not convert — more than most teams spend on the tooling they argue about.

How do you tell a real velocity change from noise?

Most sprint-to-sprint movement is noise. A useful rule: calculate the spread before you react to a dip, because a single sprint rarely carries enough information to justify a process change.

Take the six values above: 34, 41, 38, 45, 39, 43. The mean is 40. Deviations are −6, +1, −2, +5, −1, +3; squared deviations are 36, 1, 4, 25, 1, 9, totalling 76. Dividing by six gives a variance of 12.7, so the standard deviation is about 3.6 points. In plain terms, anything between roughly 36 and 44 is ordinary for this team. A sprint at 37 is not a crisis. A sprint at 31 is outside the normal band and deserves a conversation.

Apply that band to planning. If the team commits to 44 next sprint and the realistic band is 36–44, the plan assumes the top of the range every time, and half of all sprints will look like failure even when nothing is wrong. Committing to 40 with a stated range of 36–44 is honest and gives stakeholders a real forecast.

Now a slower signal. Suppose the rolling three-sprint average moves 42 → 41 → 39 over nine sprints while headcount is unchanged and scope type is unchanged. Three consecutive periods of decline with a stable team is worth investigating: check carryover trend, unplanned work ratio, and review queue depth before assuming motivation is the cause. If instead the average moved 42 → 35 → 43, you are looking at variance, and the correct response is to wait.

What mistakes make a velocity tracker lie?

Four failures account for most bad trackers, and each has a cheap fix.

Counting partial work. A story at 80% completion earns zero points. Partial credit inflates velocity and hides the real bottleneck, which is usually the last mile of review and testing. Fix: define done once, in writing, and apply it without exceptions.

Changing the estimation scale. If the team moves from a 1–13 Fibonacci scale to 1–21 mid-quarter, the numbers before and after are not comparable. Fix: start a new tracker segment with a note, or keep the scale and accept that some stories will be large.

Re-estimating completed work. Re-pointing a story after delivery to “reflect what we learned” rewrites history and makes trends meaningless. Fix: point once, at planning, and never touch the estimate again.

Using velocity as a target. This is the expensive one. The moment velocity appears in a performance review, estimates inflate, small tasks get split into three, and the number rises while delivery stays flat. Fix: report predictability and cycle time to leadership, and keep raw velocity inside the team.

Teams also over-instrument. A tracker with cycle time, lead time, throughput, WIP, escaped defects, and velocity in one sheet is impressive for a month, then nobody updates it. Pick velocity plus one flow metric — cycle time is usually the best pairing — and ignore the rest until you have a specific question they would answer.

What are the trade-offs of tracking velocity at all?

Velocity is a proxy, and every proxy trades fidelity for simplicity. The honest trade-offs look like this.

Velocity is fast to record and easy to compare across sprints, but it depends on estimation discipline that many teams do not have. Throughput (items completed) needs no estimation at all and is harder to game, but a count of items treats a two-hour fix and a two-week feature as equal. Cycle time is the best predictor of when a specific item will finish, but it says little about how much fits in a sprint. Most mature teams keep velocity for planning and cycle time for promises.

There is also a cultural cost. A visible velocity chart creates pressure to keep the line rising, and the line can rise for reasons that have nothing to do with value: smaller stories, looser definitions of done, more points per unit of work. If your organisation cannot resist turning a planning input into a league table, publish predictability instead. “We deliver 94% of what we commit to, with a range of 36–44 points” is a better management signal than “our velocity is 43.”

Finally, velocity assumes stable team composition. Add two engineers and velocity should rise after a ramp of one to two sprints; remove a specialist and it will fall even if everyone works harder. Log team changes in the notes column, because a headcount change is the most common explanation for a step change in the chart, and the least common entry in the tracker.

Who should skip a velocity tracker?

Small teams with continuous flow, support desks, and agencies billing by the hour usually get nothing from it. If work arrives continuously and ships continuously, a sprint boundary is an artificial container, and a rolling throughput count or a cycle-time distribution answers the same question with less ceremony.

Teams brand new to estimation should also wait. Until a team has estimated three or four sprints, its points have no stable meaning, and a tracker built on unstable units produces confident nonsense. Start with throughput, then add points once the team can agree on relative size without a forty-minute debate.

The tracker is worth the five minutes it takes when a team plans in fixed increments, has more work than capacity, and needs a defensible answer to “how much can we take on?” That is the whole use case. Everything else is decoration.

How does Doitify fit a velocity tracker into delivery work?

Doitify is our product, so read this as disclosure. The relevant capability is that sprint data already lives where the work does: stories carry estimates, sprint completion is a status, and reports can roll completed points into a per-sprint view without a parallel spreadsheet. Doitify’s project and performance reports cover delivery trends, and the board keeps committed versus completed visible while the sprint is running rather than only at the retrospective.

That matters because the most common failure of a velocity tracker is not the math, it is the update. A sheet that lives outside the tool needs a person to remember it on a Friday afternoon. When the log is a view over existing data, the tracker survives a busy month. Teams that want the fillable structure can still copy the columns above into a Doitify table or their own spreadsheet — the template is the thinking, not the file.

Conclusion

A velocity tracker earns its keep by making three things visible: whether commitments are realistic, where carryover comes from, and whether a change is a trend. Five columns, one note, and a rolling average do that work. The discipline is in the definition of done and in refusing to let the number become a target.

Copy the structure above, fill six rows from your last six sprints — even approximately — and calculate the mean and the spread. You will learn more about why your plans slip from that one exercise than from a quarter of dashboards.

If this post on velocity tracker template was helpful, you might also enjoy How to Calculate Team Capacity: Formula, Examples, and Best Practices and Capacity Planning in Project Management (2026 Guide).