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 she 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). In order 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 and if she is reducing the time she takes to run a marathon. What if she was just measuring the position and the number of marathons she runs per year? I’m sure she will improve and maybe she will be even closer to being the 1st. It could work… However, trying to improve the number of marathons run per year instead of trying to reduce the time it takes, would make her make decisions in the wrong 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 average lead time is equal to average Work In Progress (WIP) divided by 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!! It’s possible that the athlete at some point will need to run more marathons than the last year because they were not enough, but for the sake of reducing the take it takes! You can also use the velocity for other good things like doing forecasts, understanding how many things seem 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, 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.
