Measuring velocity is not enough to determine team productivity

Why do you insist on redefining every word? Velocity is, simply put, speed. Your message could be clear and straightforward if you cared enough to use the precision that already exists in English. Making a career by obfuscation and the use of exclusionary language is a very, very short term goal. "Scrum" is fine in rugby. Agile is an adjective use to describe quick, responsive motion and change of direction.

Get over your jargon. Tomorrow, it will be soooo yesterday.

I use velocity for estimating deliveries. Productivity is such a vague concept and by stating that developers productivity is met using this, I see a risk that the developers start changing their original estimates to heighten their velocity

Thanks for your contribution to this thread. It's an important topic and I think many teams can learn from good feedback on how to use Velocity.

Good post. In general agreement over not using velocity for gauging productivity, and keeping it tight with estimating how much can reasonably be expected from a team in each sprint.

But while we're on the subject of terminology, why use the word "efficiency" when you seem actually to be talking about effectiveness?

And yes, function points, however ugly, can help to measure effectiveness (or even efficiency, if that's of interest).

But what our industry needs - and many are crying out for - is a (teachable) method for measuring (business) value delivered, from the perspective of each and every stakeholding constituency. i.e. The contribution of each sprint to the stakeholders' bottom line, etc.

For me, "effectiveness" is exactly this.

How cool would it be to be able to measure this?

Thanks all for the great feedback.

Couple comments on what was said.

Regarding inflating Velocity - I agree that it's easy to do, but typically I find no point in doing this as it's really the measure for the team and the team typically won't want to try and fool themselves.

Regarding efficiency. I should look up the definitions of these terms before I use them :-) I probably did mean effectiveness. Thanks for pointing that out.

Regarding Value - I saw a great video online by Amr on Value. And as he so rightly points out Value is in the eyes of the beholder i.e. it depends on the context and whose eyes you're looking through. That's why I think its going to be really hard to come up with a standard measurement for all teams and that's probably not the only reason.

I think I should address this whole Value thing again.

THanks folks
Jack

I really liked the points that you made.

What I have found is that if management is obsessed with productivity, then there is a lack of trust. Perhaps this needs to be looked at - maybe there is a perception that people are slacking off.

What I have also found is that business is often far more interested in predictability. They need to be able to plan effectively. The key to being predictable is delivering on commitment and having a stable velocity.

Nice article and I agree with most points. Velocity is definitely not the only metric by which to measure a team's productivity or success but as you stated is still a useful tool in the agile dev. toolbox.

As for the first commenter, I am afraid he may not have been previously exposed to agile development practices. Either that or I have no idea what he was getting on about.

Janusz you raise a really good point here. In the past I've used the burndown chart during a Sprint to show the management "what" could happen "if" they pull the resource off task or mess around too much with the Sprint Backlog tasks. I forecast the disruption, learning curve for the new team member and changed effort remaining into the future; a little bit of smoke and errors I admit, but very useful to watch their face when the forecast burndown line either flat-lines or starts to track north of the velocity line. They can instantly see the impact on time and scope (and therefore cost and benefit) - much more powerful than a gantt chart with slipped tasks and milestones.

Let's say you have a project that has been running for two years. What chance do you have that a story that your team has estimated at say, 5 points at the beginning of the project (when nobody had any clue about how big the stories really were) is the same 5 points that your team is assigning to a story now, when they are experts and have high confidence? I say the chances of not fluctuating the "standard" point value are close to nil. Also - it doesn't really make much sense to be too anal about precise and constant story point sizing - as long as the stakeholders are happy with results.