Back in 1996 I took up golf. I was terrible at it. Like most people who take up a new hobby, I spent a good bit of time (and money) trying to improve.
I went to the driving range a couple times a week, I watched the Golf Channel to pick up tips and tricks (YouTube wasn’t the powerhouse of tutorials it is today), and I read a few books too. But the thing I found most helpful, was actually playing. When I was at my best, I practiced and played a round at least once per week.
When I first started playing, I realized many of the more experienced players could easily recall how well (or poorly) they played every stroke in a round. At first, I thought they had better memories than me, but I quickly realized it was easier for them to remember because they typically hit 20 to 30 less strokes than me. Ha!
When I first took up golf, tracking my score was enough to know if I was improving. But at some point, I realized if I was to continue to improve, I needed to know those areas of my game needing the most help. And since I couldn’t remember every stroke like my more experienced friends, I created a shorthand notation on my golf card to track key metrics to jog my memory later. As some may know, I’m known as a “metrics guy,” so this came naturally to me.
From that point forward, I tracked F stats (fairways hit from the tee), G stats (greens landed for par), number of putts, and overall score. When I found an area of my game I thought problematic, I started tracking a metric on that too. My scorecard became full of notations. Over time, I zeroed in on the areas of my game that really needed work. And that’s what I spent time practicing.
What does this have to do with agile and velocity? Over the past few years, I’ve seen many Scrum Masters and Agile Coaches eschew the use of velocity as a useful agile metric. The common reasons given for avoiding velocity are:
- the tendency of leadership to compare velocity of different teams, looking for ways to reward or punish them based on the number of points they commit to and/or deliver
- teams spending too much time trying to fit stories into certain norms for points, i.e., every story must be 5 points
- teams arguing over estimates because velocity needs to be accurate
- teams sandbagging their estimates and velocity due to pressure from leaders to get more done
Many other reasons are given for avoiding velocity, but this list suffices.
What I would point out is, the bad behavior resulting from tracking velocity isn’t an inherent part of the metric itself. Rather, it’s just bad behavior. Velocity may be used as justification for the behavior but it’s not the cause. For example, leaders using velocity to compare teams isn’t bad because of velocity. It’s bad because leaders try to compare teams in ways they cannot and should not be compared. Teams spending too much time trying to get an accurate point estimate or forcing stories into a specific point, isn’t velocity’s fault. But it becomes the scapegoat for bad team dynamics, lack of collaboration, or an inordinate need to come to a perfect consensus.
Some coaches or Scrum Masters mistakenly think if they remove the metric, they remove the problem. Don’t want leaders comparing teams? Get rid of velocity. Don’t want teams agonizing over their estimates? Get rid of velocity. Then there’s no need to point stories.
I argue the opposite. My view is, velocity not only provides guidance on how much work a team should commit to, but it also identifies problems with leadership expectations, organizational dynamics, team collaboration, and more. As a coach, when I hear a manager talking about two teams’ velocities in some comparative manner, it opens up a chance for an important conversation about why that behavior, as a leader, can hurt the organization in the long run. If I see teams padding their estimates or discussing a story ad nauseum so they can point it correctly, I view this as an opportunity to coach them against these behaviors.
Returning to my golf experience, if all I wanted was making my G stat look better, I could have lied about it and written down a different number or simply picked up the ball and dropped it on the green. That doesn’t fix the problem. Do you know what else won’t fix the problem? Not tracking the G stat. The problem is the problem. The metric simply brings it into the light. And, when used properly, it ensures we focus on the right types of changes to practice and promote.
Finally, if you’re an Agile Coach, Scrum Master, or member of a team, don’t automatically dismiss velocity. Maybe your team doesn’t need it. Maybe you’ve matured beyond needing to track that particular metric. That’s OK. But maybe, you should be tracking velocity. You may be surprised what you learn.Learn more about how we can help your teams grow with our onsite and public software testing workshops.
