Scrum terms – What is Velocity ? – a brief description

Scrum comes with its own set of terms, some of which should be familiar to all of you by now. This post will talk about the term called ‘Velocity’, which in normal English is a slightly scientific way of talking about speed. You would consider that Scrum will not deviate too much when using the word, and hence in Scrum-speak, Velocity refers to the amount of work that can be done in one Sprint cycle, and is partly derived from the experiences of previous Sprints. It is a summary of all the stories that the team done in the current Sprint, multiplied by the effort taken for each story, so if a team did 3 stories with an effort of 4 days each, and did 2 stories with an effort of 5 days each, then the Velocity for the team will be = 3*4 + 2*5 = 22. Note, for Scrum, we try to stay away from marking estimates with actual time intervals such as hours, days, etc, so when measuring the Velocity, the effort required for each story is defined in something called Story points rather than time durations.
So, when a Sprint cycle has completed (or multiple Sprint cycles have got completed), the team can review the amount of work that got done in these cycles, and develop a fair idea of what is the amount of effort that they can complete in the current cycle, and that actually becomes the Velocity. As you move over time and do multiple Sprints, the Velocity will be a very useful tool that will allow you to plan and predict the amount of work that the team can do in future Sprint cycles.
What does the ScrumMaster do about velocity, especially when the team is a bit new ? Well, if the team keeps on improving their Velocity as they move ahead on Sprint cycles, then that is a good movement, and the ScrumMaster can work with the team to understand the improvements that have happened, so that these can be built on. Conversely, when the team is not able to improve its Velocity or the Velocity even reduces, it is a bad sign for the team since it means that they are not able to generate the required level of accuracy, and even improve on these estimates. However, do not get into the concept of trying to compare the Velocity across multiple groups implementing Scrum; the effort that each group puts in, the amount of work that can happen, the degree of difficulty, all of these determine the actual amount of stories that the team can complete.
However, Velocity also means that you are looking forward, not looking at the amount of work that employees are actually doing; so if that means that an employee spent night and day resolving some complex issues, in terms of Velocity, it will be defined as a reduction of the amount of work required (and you might not even credit the employee for the amount of hard work required to get the work done as per time and schedule)