Velocity Tracking Template

What This Template Is For

Velocity is the number of story points a team completes per sprint. It is the most useful metric for predicting how much work a team can take on and when a set of features will be done. It is also one of the most abused metrics in product management. When velocity becomes a performance target, teams inflate estimates to hit numbers instead of using it as a planning tool.

This template tracks velocity over time, calculates rolling averages, and provides capacity planning formulas so you can forecast delivery dates with reasonable confidence. It pairs well with the sprint planning template for setting realistic sprint commitments. For a deeper dive into product metrics that matter, the Product Analytics Handbook covers how to choose and interpret team-level metrics.

When to Use This Template

• After every sprint: Update the velocity log and recalculate the rolling average.
• During quarterly planning: Forecast how many sprints a feature set will take.
• When stakeholders ask "when will it be done?": Use velocity data to give a range, not a guess.
• When velocity is unstable: Diagnose whether the cause is scope changes, team changes, or estimation inconsistency.

Step-by-Step Instructions

Step 1: Set Up the Velocity Log (10 minutes)

Create a table tracking committed vs. completed story points per sprint. Include team composition to normalize for capacity changes.

• ☐ Create the velocity log table (see template below)
• ☐ Backfill data from the last 6-10 sprints if available
• ☐ Record team size for each sprint

Step 2: Calculate Rolling Averages (5 minutes per sprint)

Use a 3-sprint and 6-sprint rolling average. The 3-sprint average responds faster to changes. The 6-sprint average smooths out outliers.

• ☐ Calculate the 3-sprint rolling average
• ☐ Calculate the 6-sprint rolling average
• ☐ Note the completion rate (completed / committed)

Step 3: Forecast Delivery (15 minutes)

Use the velocity average to estimate how many sprints a feature set will take. Always give a range (optimistic, likely, pessimistic).

• ☐ Sum the total story points for the feature set
• ☐ Divide by the 6-sprint rolling average for the "likely" estimate
• ☐ Use the highest sprint for the "optimistic" estimate
• ☐ Use the lowest sprint for the "pessimistic" estimate

The Velocity Tracking Template

Sprint Velocity Log

Rolling Averages

Capacity Planning

Capacity Adjustments

Example

Sprint Velocity Log

Rolling Averages

Delivery Forecast: Report Builder Feature (estimated 85 story points)

Recommended commitment to stakeholders: "We expect the Report Builder to ship in late April, with a range of mid-April to early May depending on unplanned work."

Tips

1. Never use velocity as a performance metric. The moment velocity becomes a target, teams inflate estimates to look productive. Velocity is a planning input, not a scoreboard. Use it to forecast, not to judge.

1. Normalize for team size. If your team goes from 5 to 4 engineers, velocity will drop by roughly 20%. Track team size so you do not confuse a capacity change with a productivity problem.

1. Use a range, not a single number. Giving stakeholders one date is a promise. Giving them a range is a forecast. The range between your highest and lowest recent sprint is your natural variability. For more on communicating uncertainty, see the Stakeholder Management Handbook.

1. Investigate outliers. If one sprint is 40% below average, find out why. A P0 bug, scope creep, or unclear stories are common causes. Fixing the root cause improves future accuracy. Track these in the Notes column.

1. Re-estimate when scope changes. If new features are added mid-release, update the total story points and recalculate the forecast. Do not pretend the original timeline still holds. The RICE framework can help prioritize what stays and what gets cut.