Physics of Agile - All about Velocity

In High school, I always confused velocity with speed. I always used to wonder, how is it possible that speed has a numerical value and velocity at the same time zero. Relative velocity is another confusing concept and students struggle to understand it in the first attempt. 

In the present day, I am working in the Agile world, and velocity is still glued with me. I have been thinking whether to consider it as a vector or a scalar. If a person has traveled 5 miles forward and 3 miles backward in 1 hour towards the starting point, it will have different values for velocity and speed as per physics. He has a speed of 8 miles/hour but a velocity of only 2 miles/hour. This is the beauty of direction. 

Now, in an attempt to introduce velocity in agile development, I am moving ahead with this analogy and comparing it to the present day Agile development environment. I have developed something in a sprint having a story point estimation of 5. I had an early feedback meeting with the Product owner and had to revert some changes, which involved 3 story points of work. So what is my velocity, 8 story points, or 3 story points? Many of you will say that it is 8 story points of work. So, velocity here is a scalar quantity and not a vector. In agile, we do not believe in going back, instead, small increments of working software are implemented. So velocity is something which has magnitude as well as direction, and that too in the right direction! That is the reason we take small incremental steps and move ahead. Exactly the same way we climb an unknown uphill. 

Imagine a hypothetical scenario, where you are participating in a mountain climbing competition. On reaching the summit, you are completely exhausted as well as thrilled, as results can be announced anytime, you are very sure of your win. You get a message from the base camp that you have climbed the wrong summit. Probably you misunderstood the map. Now what? You have time in hand, you rush down quickly to reach the correct base, from where you have to start once again. But now, you realize that the only thing available to you is the zeal to reach the top. You are out of food, water, and no energy in your body. You have a positive attitude, but that is not just enough to be there.

This scenario is no different from a particular day in a software development organization. Consider the scenario now, when you would have taken small steps and ensure after every few steps you are in the right direction. This could have been done in many ways, by looking for the correct milestones, checking messages from the basecamp, looking around, and many more ways. You may feel that you are going too slow, but you have just realized the result of going too fast in the previous example. 

We have discussed how we progress in Agile and we have something as velocity which is related to our progress. In further sections we will try to understand velocity in more detail.

Exploring Velocity in some more detail

Velocity is defined as the measure of work finished in a particular sprint. It can also be defined as the sum of the story points of “Done” work. Your team must have estimated some story points for each user story they committed to finish in a particular sprint. At the end of the sprint, story points of all stories which are in conformance with the definition of done are added and what we get is the velocity of the sprint. 

This is just the pure definition I have discussed so far. There is more to it. Good, bad, or maybe ugly.

What is bad about velocity?

We, humans, have a deep-rooted psyche to compare numbers. We even, without realization, start doing that. I can give you a live example. My height is around 7 feet.

Didn't you just compare my height to something or someone? Maybe you just looked up at your ceiling and had a thought where I would be reaching, or something similar. It is normal, it is how we are. The moment velocity becomes bad is, when it is used for any comparison or being looked up as a performance parameter. The problem is, we do not even realize when we start doing it. Be it anyone, developers, Product Owner, or even scrum master. I have seen examples where teams are compared based on the velocity. Velocity is the sum of story points delivered and nothing more than that. Story points do not have a definitive measure, they are just relative measures. So, don't you think comparing velocity is like the most absurd thing? Even teams themselves fall prey to this. They, at times, start looking at it that their velocity has decreased this sprint or have increased this sprint. Why even a team looking at it is bad? Team grows and learns every sprint.

Now, I will explain why even a team shouldn't look at their velocity. In a particular sprint, the team has estimated a complex work as 5 story points and delivered it. So the velocity comes out to be 5. In the next sprint, now as they have developed ability from the previous sprint they estimate the similar work to be of 3 story points and commit for some additional work as well which is of 1 story point. At the end of the sprint when velocity is calculated it comes out to be 4, which is less than last time. This is the crime scene. The velocity from the previous sprint is less which means less work is delivered, while in reality they delivered more from the previous sprint. They anticipated that the skill they have developed in the previous sprint, they will be able to deliver work of similar complex nature quickly and can pick some additional work and they did it.

Is it such a bad number? If my team gets to know about it will they be demotivated? It depends upon the organization's culture and how velocity is being looked at. If one doesn't even calculate velocity, it is not something you are missing in life. It is a good metric to show off, but of no value. The moment this metric is showcased, the devil of comparison makes the dance move. In organizations where velocity is used as a performance metric, those organizations suffer from the challenge of inflated estimates. Teams unknowingly inflate the estimate numbers, so that they can look good.

What is good about velocity?

One school of thought is that velocity is a great metric to measure the progress of the team. It is but when looked at rationally. Velocity oscillates every sprint. If all other factors were kept constant, team velocity increases every sprint by 8-10 percent. However, this is not the thumb rule. As I demonstrated in the example above, the velocity of the team dipped from 5 to 4, which is a dip of 20 percent. Velocity is a good number when it is kept secretive. It should be used by Scrum masters just to have one perspective to look and understand things. If the team has done the same nature of work, how are they progressing? But numbers may speak lie, so have to carefully analyze these numbers and shouldn't be trapped in them. 

As velocity fluctuates each sprint, so the best way to look at it is always an average of velocities resulting from all previous sprints, keeping all other factors constant. This number can be looked up as a help to forecast. For example, if the team is excited and tries to over-commit on something, then velocity can be looked up by Scrum Master to coach the team and help them look at the real picture. An athlete who performs 3 sets of exercises each day, can just be outstanding one day and can perform 4 sets, which is realistic. However, if the performance commitment is raised to 6 sets, then we are expecting too much heroism. It will be a miracle and it doesn't happen when expected, except movies…  :). Miracles happen when they are least expected and that is their beauty. In such scenarios, Scrum Master can coach the team by sharing with them their velocity numbers and help them forecast realistic goals.

In summary, velocity is NOT a performance metric. It is NOT a tool of comparison. It is just an average number to forecast the completion of work.