Velocity in Project Management (Agile)
Velocity is a term greatly used in SCRUM, Product/Engineering departments try to measure the "effectiveness" or "output" of a team.
A quick Google search, gives us the result of Velocity as a term in SCRUM
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by summing up the Points for all fully completed User Stories.
In short you calculate the amount of work done in a specific period of time.
V = Tasks Completed / Change in Time
What is Velocity?
A quick Google search, gives us the result of Velocity as a term in Physics. 👇
The velocity of an object is the rate of change of its position with respect to a frame of reference, and is a function of time. Velocity is equivalent to a specification of an object's speed and direction of motion (e.g. 60 km/h to the north).
Most people understand speed, or acceleration but velocity (although an easy concept as well) is missing from our knowledge bank.
So how does it differ from speed?
The main different is the Velocity is targeted, Velocity requires a target point in order to be calculated.
V = Change in Position / Change in Time
What can Project Management learn from Physics?
Velocity in both use-cases shares two points
a) It is calculated based on Time
b) It is calculated when measured against a Target
Unfortunately in Project Management, we fail to define the Target good enough and this causes issues.
Take a look at the above chart.
Imagine going from A to B, using the same speed, but first you take the Orange path and another time you take the Green path.
Your speed is exactly the same, however the Green path is quicker because it has less space to travel.
In physics, there is no way that someone will talk about Velocity and the target is not apparent, however in Product Development a lot of times we try to measure velocity but the target is not exactly set.
We focus on generating a metric to understand our "performance" but with very loosely defined targets.
The result is loosely defined performance.
What this also results is in loosing overview of work that is done, because it can not fit inside our loosely defined target.
When we usually define our targets after we have done "research" the work of research gets lost and is not measured in our Velocity as there was not really a target set and not planned accordingly.
Kevlin Henney talks about this topic in his talk Agility ≠ Speed in which he continues to discuss the topics above even further.
I will not try to summarize them, however I urge you that if you are interested in this topic to watch his talk.