Velocity

Agile Alliance defines it arithmetically. At the end of each iteration the team adds up the effort estimates for the user stories completed during it, and that total is the velocity. With it, the team can estimate how long the rest of the project will take, assuming velocity stays roughly the same. It calls that generally an accurate prediction, even though rarely a precise one.

The counting rule is stricter than most people expect. Agile teams generally acknowledge only two levels of completion, zero percent done or one hundred percent done. Its own worked example has two stories worth two points each finished and a three-point story at eighty percent, and the velocity is four. The nearly finished story contributes nothing until the iteration in which it is actually finished, which is also why velocity can appear to leap the following iteration.

Then it lists what the number is not, and this is the part worth carrying into a meeting. Velocity is a measurement made after the fact. It can help plan ahead, but it is not itself a budget or a forecast, and Agile Alliance says that phrases such as setting the velocity reveal a basic misunderstanding. Only the aggregate velocity of the team matters, and the phrase individual velocity is meaningless. There is no meaningful comparison of velocity between different teams, since they may estimate in different ways.

The Scrum Guide adds the caution from the other direction. It acknowledges that practices exist to forecast progress, such as burn-downs, burn-ups and cumulative flows, and says that while these are proven useful they do not replace the importance of empiricism. In complex environments what will happen is unknown, and only what has already happened may be used for forward-looking decision making.