What Velocity is why using it

At the end of each iteration, the team adds up effort estimates associated with the user stories that were completed during that iteration. This total is called velocity. Since the effort estimates (story pints, ideal days, etc.) are merely estimates of the perceived difficulty and time necessary to complete the backlog item, a team’s velocity is not especially useful in and of itself. It becomes a valuable metric in time, as the team completes several sprints and be able to establish a consistent velocity. Then, the Product Owner can use the team’s established velocity to determine how much work it can tackle in the next iteration(s)/sprint(s) and can have a rather good prediction on the project duration.

Although velocity looks like a simple instrument to calculate and use, there are some subtle aspects that should be considered. One is the definition of done or completed. What that is mean a user story is completed? It might mean different things to different teams but a team should agree on what it means and be consistent with that.

Secondly, in Agile, at the end of an iteration (or sprint), a user story is either done (100%) or not (0%). There is nothing in between when it comes to calculate the velocity. For example, an agile team has started work on an iteration, planning to complete stories A and B, estimated at 2 points each, and story C, estimated at 3 points. At the end of the iteration, stories A and B are 100% complete but C is only 80% complete. It means, in the computation of velocity, only stories A and B are considered so the result is 4 story points.

Velocity is also used to limit the amount of work taken on in further iterations. Considering the previous example, the team would be well advised to plan for user stories that sums up to 4 story points. This doesn't necessarily mean it will complete only that much; in fact, completing story C in the next iteration might mean that the team's velocity will, on the contrary, be much higher.

Agile teams consider both kinds of events a warning sign: failing to bring a story to completion "or" seeing their velocity "see-sawing". The expected response is to seek a finer-grained decomposition of stories so that it will better fit one iteration.

Finally there are some pitfalls with velocity that should be considered:

·      Only the aggregate velocity of the team makes sense, there is no “individual velocity”;

·      There is no meaningful comparison of velocity between teams; each team has its own approach on estimating effort;

·      In order to work for forecasting the project, all estimations has to be done in consistent way, either the entire set of user stories before the project starts or in the early iterations.

Velocity thus serves both as prediction tool and as a regulation mechanism.