Sprint Velocity Tracker

Overview

Velocity measures how much work a team completes per sprint, usually expressed in story points. It is the single most useful input for sprint planning because it grounds your commitments in historical data rather than guesswork.

Tracking velocity over time reveals patterns: whether the team is ramping up, hitting a plateau, or struggling with overcommitment. It also exposes the gap between what gets committed and what gets delivered, helping product owners and scrum masters set realistic expectations in planning meetings.

This tracker lets you log sprint-by-sprint data, visualise trends, and generate a velocity report you can bring straight into your next sprint planning session.

Tracker

Reading Your Velocity

The chart shows committed points (grey) alongside completed points (coloured) for each sprint. The colour coding tells you how close the team came to their commitment.

• Green (100%+ of commitment): the team delivered everything they committed to, or more. Consistently green may indicate the team is undercommitting and could take on slightly more.
• Amber (80-99% of commitment): close but not quite. This is normal and healthy. Minor shortfalls happen due to unexpected complexity, unplanned work, or estimation variance.
• Red (below 80% of commitment): a significant gap between plan and delivery. One red sprint is not alarming, but a pattern of red sprints signals systemic overcommitment or external disruption.

Look at the trend line across sprints, not individual data points. A steady average with occasional variance is healthy. A downward trend may indicate growing tech debt, team changes, or scope creep. An upward trend often appears as teams mature and improve their estimation skills.

Using Velocity in Planning

Velocity is a planning tool, not a target. Here is how to use it effectively in sprint planning meetings.

• Set capacity using the rolling average. The last three to five sprints give the most reliable baseline. Use this number as your starting point for how many points to bring into the sprint.
• Adjust for known factors. If a team member is on holiday, or if the sprint includes a bank holiday, reduce your commitment proportionally.
• Use the standard deviation. A high standard deviation means your velocity is inconsistent. In that case, plan conservatively and use the lower end of your range.
• Share the report. Copy the velocity summary and paste it into your sprint planning agenda or Slack channel before the meeting. This gives everyone context before the discussion begins.
• Review trends in retrospectives. If velocity is declining, discuss it in your retrospective to identify root causes.

Best Practices

• Track velocity for at least five sprints before relying on it for planning. Fewer data points make the average unreliable.
• Keep your definition of "done" consistent. If you change what counts as complete mid-way through tracking, your historical data becomes misleading.
• Include all work in the velocity count: stories, bugs, and technical tasks. Cherry-picking inflates the number and defeats the purpose.
• Never compare velocity across teams. Story points are team-specific estimates, not a universal measure. A team with a velocity of 20 may be delivering more value than a team at 50.
• Re-estimate when the team composition changes significantly. Adding or removing members resets the baseline.
• Use velocity alongside other metrics like cycle time and sprint goal completion rate. No single number tells the full story.

Common Mistakes

• Using velocity as a performance metric. Velocity measures throughput, not effort or quality. Using it to evaluate individuals or teams creates pressure to inflate estimates, which makes the metric useless.
• Gaming story points. If teams are rewarded for high velocity, they will assign more points to the same work. This is a natural response to incentives but it destroys the planning value of the data.
• Ignoring context behind the numbers. A drop in velocity during a sprint that included a production incident, a team offsite, or onboarding new members is expected. Do not treat every fluctuation as a problem to fix.
• Committing to more than the average. Optimism bias is powerful. If your average velocity is 28, committing to 35 because "this sprint feels different" almost always leads to carryover.
• Tracking velocity without acting on it. The data is only useful if it informs decisions. If you track velocity but never reference it in planning, you are adding overhead without benefit.
• Stopping tracking after a few sprints. Velocity trends take time to emerge. The longer you track, the more useful the data becomes. Keep logging even when things feel stable.

Related Tools

Related Templates