How Velocity Became a Bad Word
Why we stopped being concerned with velocity
12 September 2016
During an interview with an employer, I spoke with an executive whose understanding of Agile was centered on velocity. I didn’t think much of it until I started working at the firm and realized that a majority of the executives had this focus. The firm’s five teams were judged solely on velocity, and if the team lived up to the velocity, they felt it was a success. Velocity had become a bad word.
Why the focus on velocity?
After speaking with the firm’s ScrumMasters and product owners, I discovered that they all felt immense pressure to keep up with the executives’ warped view that "velocity is the only thing that matters." Two of the three teams were able to keep up with the accepted velocity and were often praised in front of other employees; the other three teams felt vilified.
Overall, team morale was down, and this affected productivity. The executives never took into account that each team worked on different products, which meant that the workload was varied. There clearly wasn’t an apples-to-apples comparison. Additionally, the corporate mentality hampered the ScrumMasters' ability to gel their teams. Enough was enough; I had to change this thinking.
I first had to understand why velocity was the most important thing to this group of executives. Through conversations, I learned that velocity was the measuring stick they were taught to use by another executive, who is no longer there, when this person was selling Scrum to the organization. They believed that velocity was the only way they could measure success and determine whether they were getting their money’s worth.
I do understand this way of thinking, coming from a Waterfall world where things have more of a rigid way of calculating success. I expressed that velocity is a great measuring stick but not the most important. However, the story became much worse when I found out that quality was being sacrificed for the sake of some number that, for all purposes, means little.
Shifting the focus to quality
Knowing the average number of story points a team can complete is great, but since there are so many factors that can change this number in any given sprint, why be so concerned with it? I believe in quality over quantity, and that is what I coached. I convinced upper management that velocity no longer mattered here; the only thing that mattered was the quality of the work turned in. Repeatedly, the teams closed stories for speed, and a story would come back with one or more bugs in the backlog. There was a running joke that stories never were actually completed at this company.
Once velocity was taken away and a quality measure stick was introduced, the teams' performance improved dramatically. The purpose of Agile is to bring consistent and repeatable value, not speed, to the organization. With this change also came the decision to drop story points and use days, which convert to hours. Time is something we all understand regardless of our language, backgrounds, race, or religion. We all understand that there are 24 hours in a day. Story points are great for Planning Poker® and a great way to start the conversation, but inevitably everything returns to time worked. This is especially true in a consultant capacity whereby you bill by hours worked, not story points completed.
Often the question asked is, "How long will it take to complete?" I wanted that question to stop, and I wanted people to estimate by asking, "How long will it take to achieve quality?" Asking that question makes people really think. Sprints were two weeks long, which translated to 80 hours per person. So it became easy for everyone to understand the hours required to reach quality. This approach took three terrible teams and two mediocre ones to five high-quality teams that delivered great software that everyone was proud of. In the end, the company received far better value for its investment, and velocity was no longer a bad word.
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.
Current rating: 4.3 (6 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.