Velocity (or how fast does your car go?)
One of the key elements in planning in Scrum is basing your forecast on Velocity. In contrast to cars’ performance, the Velocity used in Scrum is not a performance-indicator. Rather it is a parameter used towards calculating a forecast for a team’s or a project’s short, medium and long term.
| In kinematics, velocity is the rate of change of the position of an object, equivalent to a specification of its speed and direction of motion. For motion in one dimension, velocity can be defined as the slope of the position vs. time graph of an object. Speed describes only how fast an object is moving, whereas velocity gives both how fast and in what direction the object is moving.[1] If a car is said to travel at 60 km/h, its speed has been specified. However, if the car is said to move at 60 km/h to the north, its velocity has now been specified. To have a constant velocity, an object must have a constant speed in a constant direction. |
Source: Wikipedia, http://en.wikipedia.org/wiki/Velocity (emphasis in the original)
Not surprisingly, the photo chosen by authors of this Wikipedia term is this:
How fast can your car go? Put it to the test in optimal conditions, and measure it. For example, take the car to a race track, measure the top speed it can reach, and – voila! What you might get is along the following lines (emphasis added):
| Performance The Enzo can accelerate to 60 mph (97 km/h) in 3.14 seconds[12] and can reach 100 mph (160 km/h) in 6.6 seconds.[7] The ¼ mile (~400 m) time is 11.0 at 136 mph (219 km/h) and the top speed has been recorded to be as high as 355 kilometres per hour (221 mph).[13] It is rated at 12 miles per US gallon (20 L/100 km; 14 mpg-imp) in the city and 18 miles per US gallon (13 L/100 km; 22 mpg-imp) on the highway. |
Source: Wikipedia, Enzo Ferrari, http://en.wikipedia.org/wiki/Enzo_Ferrari_(automobile)
Photo obtained from the Wikipedia term above
Alas, when we are referring to velocity in agile planning, we mean something slightly different. When referring to performance of cars, we relate to a measurement: how fast can this car go?
When we come to plan, we want to know how fast does this car (or team, or project) go?
Of course, now this brings into context another aspect of velocity, being direction – how fast does this car go towards the desired destination?
Using a similar analogy, how fast does the Enzo Ferrari go in conditions as depicted below?
Photo obtained from Wikipedia term Traffic Congestion: http://en.wikipedia.org/wiki/Traffic_congestion
| Traffic congestion is a condition on road networks that occurs as use increases, and is characterized by slower speeds, longer trip times, and increased vehicular queueing. The most common example is the physical use of roads by vehicles. When traffic demand is great enough that the interaction between vehicles slows the speed of the traffic stream, this results in some congestion. As demand approaches the capacity of a road (or of the intersections along the road), extreme traffic congestion sets in. When vehicles are fully stopped for periods of time, this is colloquially known as a traffic jam or traffic snarl-up. Traffic congestion can lead to drivers becoming frustrated and engaging in road rage. |
Source: Wikipedia http://en.wikipedia.org/wiki/Traffic_congestion
If you were to set out in your Ferrari on a journey on the Delhi road depicted above, and I was to embark on the same journey at the same time with my 2CV, by how much time would you beat me?
Source: Wikipedia, http://en.wikipedia.org/wiki/2CV
Let me help you in getting the right answer:
Driving your Ferrari you set on a 10km journey, driving 5km/h in nail-biting traffic conditions. How much time will it take you, providing that traffic conditions are more or less static (quite literary in this example)?
As we have learned in elementary school, Time=Distance/Speed, so this short journey would take you about 2 hours. My 2CV (if I really had one 😉 ) would do it in about the same time.
Coming back to software development teams, Given that the team is developing 10 things in a two-week period, and we have a backlog of 50 things left to do, we can comfortably forecast that it will take the team about 2.5 months to finish this work.
It doesn’t matter how the scope was originally estimated, how good or Ferrari like the team is, or how brilliant or Schumacher like is your Product Owner and/or Scrum Master. All we want to do is to empirically check how fast the team is going towards the goal in order to plan our journey.
Just replace Distance with Scope, and you have the answer.
With that in mind, you can make a relevant forecast on the project:
Velocity = [Done Scope] / [Elapsed Time]: What is our velocity?
By this we obtain the value of the parameter to set in answering the questions below:
Time = Scope / Velocity: How long will it take us to complete the desired scope?
Scope = Time * Velocity: How long will it take us to complete this project?
Note, that Velocity is not necessarily a one single parameter value used in all kinds of forecast horizons. In fact, typically you will need different parameter values for different contexts:
[Team Velocity] = [Done Stories] / [Number of Sprints]: What is our team’s velocity?
[Project Velocity] = [Done Features] / [Number of Releases]: What is our project velocity?
[Portfolio Velocity] = [Done Themes] / [Year]: What is our portfolio velocity?
Note also, that the above is not applicable for everyone. One organization may need to use [Done Epics] / [Quarter] to calculate their projects’ velocity, while another may need to use [Done Things] / [Day] to calculate theirs.
What happens when we treat Velocity as an indicator of our capability, rather than as a parameter based on empirical evidence?
“Traffic congestion can lead to drivers becoming frustrated and engaging in road rage.”
Paraphrasing on the above, “Slow projects progress can lead to managers becoming frustrated and engaging in team rage.”
At this point it doesn’t matter why the progress is slow. It is more important to acknowledge that this team is now slow. Only after planning based on the current speed and direction of the team, can you try to alleviate some of the obstacles to increasing the speed. Some of these reasons may (or may not) include:
- The team is occupied with a lot of support issues, diverting from the project goal (analogous to road-works)
- The team is dependent on one or more other teams, leading to slow delivery of done things (analogous to congestion due to junctions and intersections)
- The team is working on too much in parallel (analogous to congestion due to exceeding road capacity)
- The team is working very hard, but on things not related to the project (analogous to driving very fast but in the wrong direction)
- The team is pushed too hard, leading to working too fast neglecting quality and capability (analogous to speeding beyond road conditions)
There are many other possible reasons. But when one is stuck in traffic jam, and getting all worked out about it, one tends to ignore the objective, empirical, conditions, and focus instead on the subjective, intrinsic, emotional condition. Similar things happen in projects.
Becoming agile 