What does the term velocity describe?

Velocity is used in different contexts in the context of Scrum. Most often, velocity is used in the sense of a unit of measurement that can be used to indicate how quickly a team delivers results. That is basically a very good definition. Of course, this is followed by the question of what is actually being measured and how. And there is also the question of why it is measured at all. Scrum.org recognises Velocity as a kind of additional process. In Scrum, there is no universal definition of how to measure a team's ability to deliver value to the client. Scrum is known for being open to a variety of practices, the key is to find a technique that suits the team and its tasks and needs. Velocity is one of these flexible practices.

If you look up Velocity in the Scrum dictionary, this is how it is defined: It is an optional, but often used, specification of the average amount of product backlog that is turned into a product increment by a Scrum team over the course of a sprint, which in turn is monitored by the development team for use within the Scrum team. This doesn't sound very self-explanatory. So Alex Kudinov tries to break it down and go a little deeper into the topic. The first thing to remember is that the primary goal of any Scrum team is to generate value for the customer. There is a Done Increment at the end of each sprint. So each Scrum Team turns Product Backlog items into valuable Done Increments. This can then be handed over by the product owner to the customer.

There are different ways to measure how many Product Backlogs have been turned into Done Increments. Many teams use so-called Story Points for this purpose. This approach has been described many times and tested even more frequently. However, one must always keep in mind that Story Points are always very abstract. They depend very much on how the team divides the units of its work and are therefore very project-specific. Under no circumstances can Story Points be used as a measure of team performance or productivity, even though this misconception often arises. To measure how much work a team has already done, there are other ways. Some teams record hours. This has disadvantages that Alex Kudinov does not go into in his article. Still other teams simply count the number of product backlogs that have been turned into done increments. The latter method is probably the most popular in teams using Kanban.

It basically doesn't matter which way a team chooses, as long as the team stands behind the decision and has found a way that is good for their own approach. Measuring one's own success is important and cannot be imposed from above. Moreover, this means that teams cannot be compared with each other, because each team has to find its own way to measure success. In Scrum, great emphasis is placed on using a measurement method "by the team for the team" and not by someone else. According to Alex Kudinov, measuring velocity is important for one purpose only: to serve as input in sprint planning. According to the Scrum dictionary, the following variables must be used as input in sprint planning: the product backlog, the latest product increment, the estimated team capacity for the upcoming sprint, and the prior performance of the development team. This last ingredient, the performance of the development team during their previous tasks, can be considered the Velocity, but it does not have to be - or at least not exclusively. Any kind of measure can be used here, depending on what the particular team decides to use. Alex Kudinov reminds us here once again that Scrum is only a framework in which all kinds of practices can be applied. 

Have you heard that the goal of Scrum is "to do twice as much work in half the time"? Wasn't that in Jeff Sutherland's well-known book? Many have heard of it and ask experienced Scrum Masters about it again and again. After all, it sounds tempting. Doesn't it? Alex Kudinov emphasises that a good Scrum Master is there to coach his teams and help everyone to use Scrum in the best possible way. Unfortunately, many take Jeff Sutherland's famous quote the wrong way, or at least too literally. Scrum is not about doing everything four times too fast. Scrum is only there to concentrate on the result, on the output and on the added value actually created. The idea is to work in the most effective way through continuous adjustment, questioning and complete transparency. Whether this saves half or a quarter of the time is beside the point. What matters is getting the job done as quickly and as well as possible, without getting bogged down in errors, misdirection, bureaucracy and procedures. Velocity in this context is not suitable for measuring how valuable your end product really is. Other methods must be used for that. However, Velocity can certainly be a tool on the road to success if your teams want to assess themselves at work.