Is Velocity Evil? (No.)

In a webinar today, someone said that Velocity is evil if equated with productivity.  I disagree.  And partly agree.

 

First some explanations (short, maybe too short for some):

The Velocity of a sprint is the number of story points that the team “earned” (completed) that sprint.

It’s the way we score in the game of Scrum.

Well, I would say Velocity is really the average velocity over the last 3 sprints. It is the real-world productivity of the team given all the real world issues (eg, despite plenty of impediments).

It’s part of the game, and gives transparency.

Nothing in life is a precisely accurate metric. “Business” metrics are less precise than scientific metrics, typically.

Still, a rough measure can help guide action.  But, as Yogi Berra said, take it with a grin of salt. (sic)  In scrum we say, it depends on common sense.

Poor Estimation

It is true that some teams are poor or weak at estimating.   For this short post let just say that that can be fixed (a lot) in a relatively short time.

There are a number of other key factors in using Story Points well.

Productivity

Compared to itself (in prior sprints), an upward productivity movement should be reflected in an increased Velocity (for the Team).

If the Team uses SPs fairly well.

By productivity, we mean “work units” (SPs) done per sprint (eg, in 2 weeks or 10 business days).

Is it very accurate?  No.

Accurate enough to be useful?  I think yes.

Other Productivity Measures

The more important productivity, really, is BV delivered.

Business value delivered to the customer generally measured against some product that was built in some timebox (eg, in 3 months).

But people never call this “Velocity”.

Can Velocity be used badly?

It can be and it is used badly. Regularly.

We mentioned the poor estimating.  At some point this poor estimating seems intentional.  So, there can be that problem.

Managers want to use velocity to compare teams.  No, do not do that. (Ok, it can happen, but I am immediately concerned.  And I discuss this elsewhere.)

Managers can “demand” that velocity increase by X%.  Demanding this is wrong and foolish.  Asking about and supporting (in useful ways) the continuous improvement that leads to notably higher velocity is reasonable.  But just saying “work harder” is usually both mean and stupid.  (If a manager says “I think your team could work harder on X” — that could be the start of a useful conversation.)

Other Problems

If a manager puts pressure on Velocity, Teams commonly cut quality to achieve the goal.  Bad!  Cut quality or something else important.

But this and other similar problems can be avoided with a little attention.

Good Uses

The Team can set a goal for itself to increase velocity by fixing impediments.  That gives them focus on identifying and fixing impediments.  Working smarter, not harder.  Good!

The Team can enjoy the game of the sprint, and enjoy the “small wins” as the score (completed SPs) goes up.

If the Team “wins” the Sprint (ie, completes the SPs they committed to), they should celebrate.  And that helps.

The Team can see if they are flatlining.  Not good in the hospital, not good for a Team.

If a Team has improved a lot, they might start to compete with some of the best Teams in their area (city, state, country).

To be fair, it is hard to compare teams in an apples-to-apples way.  But the competitive energy (if reasonable) and the desire to improve by observing what some other team does, can help your team get a lot better.

 

Closing

Life is a game. Never take it too seriously.  You win some, you lose some.

But most people like to play games. Games with scores. And we (eg, we in business) can use that to help build a great team.  Or a much better team.

 

***

It is impossible to convince some people not to hate story points.

But I hope these words, said quickly, help some.

 

 

 

« « What is Scrum? – by Ken Schwaber || What if one Team member does not agree with the process? (eg, to do “scrum”) » »