What do we want when developing a new product or new features for a product? To delight our users, obvious, right? Nobody works to have unhappy users… How do we delight our users? By delivering something they want, the sooner the better. However, instead of measuring “we delivered what they want” and “the sooner the better”, what most teams and companies measure is “how many things we deliver”, known as velocity. Don’t be like them!
Imagine, for instance, an athlete that runs marathons and has a clear goal, she wants to win a marathon, therefore she needs to reach the finish line first (aka “as soon as possible”). For this reason, she will measure the exact position she finishes (“what our user wants”) and the time she takes to run a marathon (“the sooner the better”). To improve, she will try different workouts, diets, food supplements, run some marathons during the year, etc.. and then will check if she is closer to the 1st one or not, and if she is improving the time she takes to run a marathon or not. What if she just measured the position and the number of marathons she ran per year? She might improve and maybe she will be closer to the 1st one. It could work… However, trying to improve the number of marathons run per year instead of trying to reduce the time it takes, won’t help her to make decisions in the right direction towards being the 1st one: not taking enough time to rest from one marathon to another, choosing marathons that are not her best fit, going to amateur marathons that are easy to win, etc…
Velocity is important, it’s one part of Little’s Law as the average lead time is equal to the average Work In Progress (WIP) divided by the average throughput (velocity). This means that if you want to reduce time, you need to reduce your WIP or increase the velocity. Still, the important thing is to reduce time!! The athlete at some point may need to run more marathons than last year because they were not enough but for the sake of reducing the time it takes! You can also use the velocity for other good things like doing forecasts, understanding how many things you will be able to deliver, how healthy is your system, etc… But using it as the most important metric, as we said before, would lead you towards making bad decisions that will impact the company: resources utilization over efficiency, burnout teams, starting new things over finishing them, too much unfinished work, an increase of your lead time, less flexibility to change direction, too many WIP, etc… and all these things we have just enumerated, from my point of view are not how an agile environment should be.
