Metrics & Velocity

I have received a few comments, both recently and in the past, that tell me some people are uncomfortable measuring velocity.

And they are uncomfortable measuring the team. They are usually not that clear why they are uncomfortable.  Some feel it does not help.

Let me state my position, which I believe is also close to the position of Jeff Sutherland and Ken Schwaber.

First, as a memory device, I say: “Velocity: Don’t leave home without it.”

Second, any decent team wants to know if they are really successful.

Third, the team must measure velocity and it must aggressively try to improve it. Doubling velocity in the first 6 months should be a goal. And not an empty ‘goal’, but an attainable goal. In Scrum, the larger goal is to get the team to be 5 to 10 times more productive than the average team. (Good data tells us that the average for a waterfall team is about two Function Points per man-month.) Scrum does not guarantee that every team will get to 5 to 10 times more productive, but none will if they don’t go for it.

And every team should want to improve, and want to be able to see whether or not they have improved. Yogi Berra said, “If you don’t set goals, you can’t regret not reaching them.” But the team is stronger than that. (And Yogi, who has 10 World Series rings as a player, definitely set goals for himself and his team).

Improving velocity means removing the top impediment, one at a time. It does NOT mean working harder. In fact, often, one of the top impediments is that we are already working too many hours per week. (To some, this will seem a paradox. Explanation another time.)

How do we use velocity? Many ways, but I will emphasize three.

  1. In planning, to re-estimate the release date, for example.
  2. To push back, with a pattern of numbers, when a magical-thinking manager asks the team to double their velocity in one Sprint.
  3. To challenge ourselves, as a team, to get impediments removed so we can enjoy some real success around here. (And often we have to ask managers and even senior management to get involved with the impediment removal.)

What are the push-backs that I hear?

Several. This post is getting long enough that I won’t state them all here.

The cartoon represents one of the major ones, I think. People are concerned that we are putting human lives in the hands of some stupid bean counter (as we say in the South, “Bless his little heart”). Certainly not a happy thought.

So, a few assertions about metrics (not time here to discuss them):

  • the team does the metrics themselves because they want to use the numbers
  • there should be no “managing from behind the desk” (as Lean would say)
  • velocity does not reflect one single factor, but the result of all factors
  • when the team evaluates velocity, they use human judgment (ex: “The velocity dip last Sprint was mainly due to Vikas being out sick four days; he’s fine now.”)
  • people want to see clearly and show that they are successful
  • velocity is not supposed to be a tool for Dilbert managers to beat up the team
  • while every metric might be gamed (e.g., due to Dilbert managers), these issues are part of the larger imperative of honesty and transparency in Scrum; occasional gaming is not a reason to never do any metrics
  • velocity is not the only important metric
  • delivering business value to the customer is more important than any metric (the metrics may be a ‘means,’ they are not an ‘end’)

« « Fun & Success – Learn Scrum || New, special Classes – I’m excited » »


One thought on “Metrics & Velocity

Leave a Reply