Forecasting
Sprint velocity is the number of story points a team completes in a sprint, averaged over time. It is a planning tool that turns past delivery into a realistic forecast, but it becomes harmful the moment it is treated as a performance target instead of a measurement.
Add up the points of the stories fully completed in a sprint. Do that for several sprints and take a rolling average. A single sprint is noisy, but three to five sprints reveal a stable range the team can plan against.
Only count work that actually met the definition of done. Partial credit for unfinished stories inflates velocity and quietly breaks the forecast you are trying to build.
If a team averages thirty points per sprint and the remaining backlog is one hundred and fifty points, the work is roughly five sprints out. That estimate improves as the backlog is refined and the average settles.
Present forecasts as a range, not a promise. Velocity captures typical throughput, but scope changes, dependencies, and absences all shift the real date, so a range communicates honestly.
The moment velocity becomes a target, teams inflate estimates to hit it. Points drift upward, the numbers look great, and the forecast becomes meaningless. Goodhart law applies directly.
Compare velocity only against the same team over time, never between teams. Two teams point work differently, so their numbers are not comparable and ranking them rewards estimate inflation rather than delivery.
Usually three to five. Fewer than that is too noisy to plan against, especially for a new team still calibrating its point scale.
Only if you point that work. Many teams leave small bugs unpointed and simply account for them by not filling the sprint to the brim.
Holidays, context switching, unclear stories, and carrying unfinished work between sprints. Investigate causes rather than pressuring the team to push the number up.