Seven Ways to Fail at Scrum -- Part Three

Here is Part Three in my series on bad Agile smells I've observed.

Smell #4: Secret Calculations for Velocity

I'll admit, when I heard about this one, my jaw literally dropped wide open with a "Whaaaaaaa...?"  I don't think I even added the terminal "t" to the word.  This is one of those bad smells that you can't even conceive where it came from or what motivated it.  I want to think it's unique to the company where I saw it, but as Solomon once mused, "there is nothing new under the sun", so I'm sure it's happened before and may still be happening elsewhere.

In this particular company, one of the managers is responsible for "calculating" the velocity for all of the teams working on the product.  I've quoted the word "calculating" because, while that's what she says she's doing, I'm suspicious that she's actually creating velocities as a way of motivating her teams.  I should also note that this product group is guilty of Smell #5 below -- correlating story points directly to man hours.  The Managers have unilaterally decided that one Developer working with one QA Engineer during the course of a sprint defines eight story points -- essentially assigning a velocity of four points per person per sprint.  The velocities the teams are challenged with (and I use that term intentionally in this case) tends to be slightly higher than that raw calculation, which fosters my earlier suspicion that the secret calculation is aimed at pushing or motivating the team.

So why is this a bad smell?  Because it hits hard against two core principles of Scrum!

The first violated principle is that of Transparency.  Velocity should be a simple matter of looking at a team's average story points over the most recent sprints.  It's not hard to calculate and it should be something transparently presented to the team as a statement of the team's current performance and predictor of future performance.  In this product group, velocity is being used as a whip against the team instead of as a tool for Product Owners to predict what features are likely to fit into the next release.

The second principle violated is -- you guessed it -- self-organization of the team.  (It's amazing how many bad smells come back to a violation of self-organization, isn't it?)  The team uses velocity as one of its indicator tools when preparing a sprint during the Sprint Planning ceremony.  Combined with predicted task hours, velocity is a way of sanity checking whether or not the team can complete the work it is about to commit to.  If a team tries to commit to 40 points of work when its established velocity is 20 points, the Scrum Master needs to be throwing flags on the field -- even if the tasked hours look feasible.

Smell #5: Correlating Story Points Directly to Ideal Man Hours

This smell is pervasive.  It's hard to get past.  We all want to quantify our work in terms of time.  It's natural.  We've been asked to do it all our lives.  

"When will you be finished?"  

"What time can I expect you?"  

Relative sizing isn't hard, but it's hard to break ourselves from the habit and mindset of predictive hours.  It's especially difficult for individuals with a scientific or pedantic bent; less so for those who are more kinesthetic.  This is complicated by the fact that we see the Product Owner (correctly) using our Velocity to project features against a release date, so, as developers, we see another argument to correlate back to time.

But despite what you might read in Henrick Kniberg's otherwise excellent and seminal white paper "Scrum and XP from the Trenches: How We do Scrum", story points need to be about a from-the-gut feeling regarding a story's size and not an estimate of time.

The psychology and reasoning behind why we should size things from the hip and relate them to the bigness of a well-understood story is a topic way beyond the scope of this particular series, but it has been exhaustively discussed throughout the Scrum literature.  For the purpose of this post, let's just take it as given that relating story points to any unit of time during the sizing phase of a story is a Bad Thing.

If there's curiosity about sizing expressed in the comments, I'll consider making a more in-depth post.