Sprint Velocity Calculator

Story points completed per sprint, averaged over the last several. Only completed work counts — partially done items carried forward inflate the figure and then deflate the next one.

Three to five is the usual advice. Fewer is too noisy to forecast from and more starts including a team that no longer exists in the same shape.

Because velocity varies, sometimes by a factor of two between sprints. The best and worst observed sprints bracket the realistic outcomes, and a range is what an estimate honestly is.

No. Story points are relative to a team's own baseline, so one team's 30 and another's 30 are not the same quantity of work. Comparing them is meaningless and using it as a target corrupts the estimates.

Holidays, people leaving, a sprint spent on an incident, or work that turned out harder than sized. A single low sprint is noise; three in a row is a signal worth investigating.

No. The moment velocity becomes a goal, points inflate and the estimates stop describing anything real — a textbook case of a measure ceasing to be a good measure once it becomes a target.

Only if that work is estimated in points like everything else. Unestimated interruptions consuming half a sprint while velocity is measured on planned work only produces a figure that forecasts nothing.

Holidays, illness, incidents, work that was sized wrongly, and changes in team composition. Variation of 30% either side of the average is entirely normal and is why a range beats a point estimate.

Carry the item and count its points in the sprint it completes, not partially in both. Splitting credit across sprints makes both figures wrong and the forecast worse.

Not for several sprints. A new team's estimates are unstable while it establishes a shared sense of what a point means, and forecasting from the first two sprints is forecasting from noise.

Only with an explicit allowance for it. Unrefined work is systematically underestimated, and a forecast that treats a rough backlog as fully understood will be wrong in one direction consistently.

Counting completed items and forecasting from throughput, which some teams find more stable and harder to game. It works well when items are broken down to a roughly consistent size.