Why Velocity Shouldn't Be Used as a Metric for a Team's Performance
2 July 2014
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Often, development managers or people from the business who perhaps don't fully understand Scrum begin to view a team's velocity as a performance metric. This leads to the inevitable question: How can we increase a team's velocity? This may superficially seem a reasonable question, but there is a significant problem with thinking about velocity in this way.
Let's imagine a scenario in which you and I are CTOs of competing companies in a market space with many other competitors just like us. Coincidentally, we both hit upon exactly the same idea at the same time, and we both go and excitedly tell our development teams about our new idea. Both our product owners agree that the idea should be our highest priority, and both our development teams begin working on the enhancement at the same time.
Continuing our unlikely set of coincidences, we both have identically sized development teams with equal technical ability, and over five one-week sprints they both deliver a solutions that are pretty much the same. We both launch our new enhancement to the market on the same day, and we're both vindicated as our idea sweeps through the market, stealing each of us the same amount of market share from our competitors.
So, we have a situation where both of our development teams have delivered the same value to our respective businesses and we have each reaped the same rewards. However, there are some differences that aren't apparent from the description above. When our teams were estimating the stories for our award-winning new feature, your team allocated 50 story points and my team allocated 100 story points. Both our teams delivered all the stories in 5 weeks, because your team has a velocity of 10 story points per sprint and my team has a velocity of 20 story points per sprint. Despite my team having a velocity that is double that of your team, my team delivered exactly the same value to the business that yours did (which is really what's important and what actually ought to be our focus). It's worth reiterating this point: All other things being held equal, our teams delivered exactly the same value to the business despite having vastly differing velocities.
Let's further imagine that you and I had met at a networking event some months before the scenario outlined above, and over the course of a conversation we realized that my team had double the velocity of your team. I also smugly told you that my team used to have a velocity of 10 about a year ago but I had mandated that their velocity needed to improve and in the space of a couple of months it had doubled. What I didn't realize while I was recounting this tale of managerial excellence was that all my team did was learn to double the number of story points when they were estimating, which led to a doubling in their velocity. Unbeknownst to me, they were delivering exactly the same workload as they had previously. In other words, they hadn't become more productive at all, and even though their velocity had doubled they were still delivering exactly the same value to the business (did I mention that delivering value to the business is what's really important). Unfortunately, you would most likely have left our conversation having resolved that you should also begin working on doubling your team's velocity.
To better understand why velocity isn't a good metric, let's unpick what a metric is and how we determine a team's velocity. According to the Oxford English Dictionary, a metric is a system or standard of measurement. A Scrum team's velocity comes from a historical average of the number of story points it has been able to complete. However, the story points are often determined by a group of people playing Planning Poker -- an activity that can be crudely summarized as a group of people agreeing on a best guess. Whilst Planning Poker could be argued to be a system, it certainly doesn't agree with the definition of a measurement.
There's also nothing standard about the estimation of story points. If you give 2 teams 60 seconds to pack fruit into a box, one team may pack 40 fruits into its box whilst the other may only pack 15. Using a simplistic numerical analysis, the first team has been much more productive -- until you realize that it was packing lemons and the second team was packing watermelons. This underscores the idea that there is no standard measurement for a story. Two teams estimating the same story will most likely assign different story points (or use different size fruits). The point is that the teams can use story points to figure out what they can commit to in a sprint (or how many fruits they can fit into the box).
We can summarize with another analogy. It turns out that velocity is actually a really good name for what it represents. Let's take an example from a school maths test. If a car's destination is 100 miles away and the car is driving at 100 mph, how long will it take the car to reach its destination? It probably doesn't take a maths genius to work out that it's going to get there in an hour. You pressure your team to increase the car's velocity, so they begin to report the car's speed to you in kilometers per hour. You now have a velocity of 161 kph. However, the distance to the end is 161 kph and it's still going to take you an hour to get there. But hey, the numerical value that's been ascribed to your velocity has jumped dramatically!
If you want to increase your team's performance (ahem, otherwise known as the value they provide to the business), then appoint a good ScrumMaster, allow them to self-organize, and other than helping them remove the impediments that they report to you, just stand back and leave them to it -- they're the experts. If you don't trust your team to work in this way, get a new team or use a method other than Scrum that's suited to more of a command-and-control structure . . . Waterfall, anyone?
Current rating: 4.7 (3 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.