Velocity is the average amount of work that Developers can complete per unit of time (usually Sprint).
Velocity is NOT an element of Scrum, but an optional practice that you can use.
Unfortunately, usually companies use it in a bad way. The most famous way is to use it to compare the performance of multiple teams. If you use it in that way, you will see 3 consequences:
1- Estimation inflation: As Developers see they are being compared with other teams with velocity, from now on they announce higher numbers in estimation to keep a safe side for themselves, and of course, at the end of the Sprint show larger numbers of velocity.
2- Cutting quality corners: They get an internal trigger to cut the quality corners of creating technical debts to finish the work sooner and show beautiful numbers of velocity.
3- Wrong center of attention: Developers get a tendency to focus on increasing velocity numbers instead of focusing on creating value for the customer.
But be aware that each team has its own specific situation and context, so the velocity is meaningful just for them. In addition, it shouldn’t be used as a commitment to create the same velocity in each Sprint, because it can establish a wrong expectation that if a team doesn’t create a predefined amount of work in a Sprint, it doesn’t work perfectly.
In addition, it is unreliable when used as a target rather than a measure. Once I heard a great quote:
Velocity as a metric is terrible; as a measure is terrific.
Imagine you are driving your car on a highway. Nowadays, speedometers on the dashboard of regular cars show a maximum number of around 250 Kilometers per hour.
Do you have a goal to achieve that maximum speed? Absolutely not. So, then why do we have the speedometer on the dashboard?
It is there just give us momentary data to keep our driving safe, that's it.
For example, if the maximum allowed speed on a highway is 120 km/hr and your speed is 130 km/hr, you see the current speed and decrease it to come back under the maximum allowed speed. Just-in-time inspection and adaptation.
Then, when can we use velocity in a proper way?
The only place that velocity can be used in a proper way is By Developers For Developers as a guide in the Sprint Planning.
Imagine the average velocity of a team over the past three Sprints is 20 Story Points. Now, for the new Sprint, Developers know that their reality is something around 20 Story Points. So, they use it as a guide and pick something like 18, 19, 20, 21, or 22 Story Points. They can't say this Sprint we want to be a hero, so let's pick 50 Story Points.
--------------------------------------------------------------------------------------------------
If you are a Product Owner and want to learn how to effectively leverage AI for the new generation of product management, you can attend my upcoming Professional Scrum Product Owner – AI Essentials class. Click here to see the class information.