How to use it
Velocity is a measurement, and the only thing it can tell you is how much this team, with these estimates, has been getting through. Enter the history first and resist adjusting it. A sprint where half the team was at a conference still counts, because sprints like that keep happening and the forecast needs to know how often.
Enter the sprints, oldest first
Count only items that met your definition of done inside the sprint. Partial credit for work in progress defeats the purpose, because the forecast is about finished things. If an item spans two sprints, count it in the one where it finished, and accept that this makes one sprint look thin and the next look fat. That variation is real and the forecast uses it.
Six to ten sprints is a good window. Fewer than three and there is nothing to sample. Much more than ten and you are including a team that no longer exists, with different people and a different codebase.
Read the stability verdict before the average
The standard deviation is divided by the average to give a coefficient of variation, which is what makes the verdict comparable across teams with different point scales. Under 15 percent the team is steady and the average is a usable planning number. Between 15 and 35 percent it is variable, which is where most teams sit, and you should plan with the range. Above 35 percent the average is close to meaningless, and the useful move is to find out why rather than to forecast harder.
Forecast with probabilities, not a single date
Dividing the backlog by the average gives one number, and that number is right about half the time. The Monte Carlo forecast instead plays out a thousand futures by drawing sprint results at random from your own history, then reports how many sprints it took at three confidence levels. Quote p85 externally, plan internally against p50, and use p95 when somebody is making an expensive commitment on the back of your date.
The forecast inherits every flaw in the history it is given. It assumes the team stays roughly the same, the backlog estimates are in the same currency as the completed ones, and nothing is discovered mid-project that adds a large pile of new work. The last of those is usually the one that breaks it, so re-run the forecast every sprint with the backlog as it actually stands.
Keep it a signal, not a target
Velocity is only useful while nobody is trying to move it. The moment it becomes a target, the cheapest way to raise it is to inflate estimates, and estimates cost nothing to inflate. Goodhart put it as a measure ceasing to be a good measure once it becomes a target, and velocity is close to a textbook case: the thing being measured is a unit the team defines for itself.
The same reasoning rules out comparing velocities between teams. A point in one team is a local unit of relative size agreed by those people, so twenty points there and forty here says nothing about either team. Compare a team against its own history, and only to answer questions about predictability.