Velocity, the False Metric of Productivity

What should be the alternate to velocity?

Ultimately, value to the customer (but it could be value to the organisation too) - velocity is just an indicator that work is churning some output but the question is always qualitative i.e. Does 200 points of work done translate necessarily to 200 units of value? Or does a mean reduction of 30 points of work done necessarily mean the output is 30 units of value less? Off course not - it's a bit like looking at the speedometer of a car without appreciating what the car is delivering - much like trucks are slower than ferraris but deliver more (but ferraris get there quicker, so a lot depends on business mode).

To me it's complex, you need to measure velocity to inform estimation not to measure productivity. Very often, you see a drop in velocity brought about say a reduction in technical debt because the team were forced to attack that (often unmeasured metric) and create enablers. Or velocity dropped but customers really appreciated what was delivered in the iteration and sales grew, etc, etc.

Great post. It really captures the essence of velocity. I'll distribute it to my agile core team to read. Thank you.

A bold article, but with some points that I feel are not hitting the mark exactly. For me productivity, in a practical sense for software companies, means the rate of progress towards completion. Velocity is the speed of something in a given direction. Story tasks should point the team in the correct direction (I agree they don’t always) and thus Velocity seems like a reasonable measure to use. However, what does hit the mark in this article is the conclusion that a team’s “Velocity is an output not a desire”! That is a very important point. In my experience Velocity is also highly volatile, especially if the stories are not estimated properly in the first place – which can lead many to dismiss the value of Velocity.

Parking lot diagrams, which have origins in FDD, can be a good measure of value based velocity; it would be based on team velocity sans time spent on course correction / change of direction. IMHO these two combined should give a reasonable view of productivity of overall system (not just scrum team). However I have experienced that in most of the organization team velocity is directly equated to ROI and teams are given target to achieve X velocity

Simplistic view of productivity. Why bring velocity into it? Velocity has more than one use in software developing. It can show if a team is having issues in their Scrum processes such as splitting stories, refinements and respect for definition of ready (for sprint). A Scrum practioner with experience can easily add to these. Badly used, any practice can hurt a project and any good ScrumMaster will never use velocity to track productivity.

Very aptly put, Paul. The challenge is, a lot of people still consider "Velocity" as the metric of productivity and hence we have to keep explaining it.

Thanks for the feedback Ben.
I do agree to some extent that rate of progress towards completion, is productivity. But what happens when this rate of progress is compromised (which is quite easy with Velocity) or when people become obsessed with productivity measurement. I also see another behavior challenge associated with it and that is "resource utilization". People are treated as resources; I have often heard terms like - hey you are not 100% utilized pull in some more story points that also increases team velocity or hey looks like you are only 50% occupied, let me allocate you to another project so that you are more productive.

As long as we measure productivity over value delivery, I believe we will not be able to provide teams with the environment that fosters creativity, value optimization or self-organization.

Thank you Erez.
I am happy that it helped.

Thanks for the answer Shalom :)
My thoughts are on the same lines.

That said, I would hope to read more articles recommending the benefits of velocity. That would help disaligned folk get back on the right track. A bit like raising kids: they cannot learn positive ways to do things if parents keep saying they are not doing it right without showing what the right way is. ..

Piyush, I already agreed with you that Velocity is an output not a desire. As I said Velocity is highly volatile (is affected by many things) - so when I hear people say "hey you are not 100% utilized pull in some more story points" then this is obviously not a good approach.

Velocity is a metric for the team to help with sprint planing in addition to being helpful to the PO to track long term goals. It helps the team to gauge how much work they can take to the sprint by looking at the historical velocity trend.

Adding business value to the stories by POs to see the business value gained at every sprint as a metric.

Assign planned Business value to Sprint objectives during sprint planning. During Sprint Review, assign actual business value after system demo.
Or another metric is process efficiency which can be used across domain or technology.

Again, we have Industrial Age thinking applied to a scrum concept. Not in the article of course, but in the way most traditional managers view velocity. They simply can't seem to wrap their head around the fact that velocity doesn't mean X many widgets produced over X many hours. Tell a traditional command and control manager that the velocity of a team doesn't necessarily equate to that and they will look at you like a caveman contemplating fire. It's up to us as agilists to deliver that message and to protect our teams from becoming victims of that kind of thinking. Our velocity is ours. We use it to plan capacity. If we have a velocity spike in a sprint, that should be mean we delivered more value for the business, NOT that we (pick one or more of the following): a) Worked more hours, b) Just got more points in the sprint, c) Got x many more user stories done off the backlog.

Wanted to understand what is missing for given scenario - If have a 1 story of 13 Story Point, throughput will come 1, but if same story is divide to 13 stories of 1 story point each, throughput will come as 13, thus it will show higher throughput achieved but in both case velocity will remain same, what to choose in this scenario

Very nicely articulated @Piyush Rahate@piyushrahate:disqus. I agree with you totally. Velocity is just a look-back, for future capacity planning; but NOT a productivity to be targeted at. If Productivity is brought in Agile way of working, then Agile becomes FrAgile.

How about using a completion rate in the Velocity metric where Completion Rate = (Completed tasks / Commtited tasks) %. This is neither helpful with productivity nor with forecast but with evaluating how good Sprint Planning is and how it is improved by time. As long as people are not obsessed with achieving 100% completion rate, isn't this a useful enhancement in the Sprint Velocity metric?