I happen to participate in a couple of Lean and Agile subject matter groups on LinkedIn. This is my way of learning and sharing. In my opinion, any serious Agile practitioner should join and participate in such types of groups (no it’s doesn’t have to be on LinkedIn). I personally learn more from these groups than from workshops and certifications classes.
I’ve observed over the past year that not a week or two goes by without someone having a question around Agile velocity on one of these discussion groups. Interestingly enough, their questions are never about how to use velocity for forecasting and/or planning. No, the questions are always about how to increase or improve their team velocity. As an example, check out this very recent velocity conversation.
Why are so many of the velocity questions focused primarily on productivity?
Unfortunately, many of these well-intentioned posters find themselves in organizations where velocity is considered to be a primary measure of productivity. Not only do organizational leaders use velocity as a measure of productivity, we find some Agile practitioners (sometimes unintentionally) doing so as well. I’ve seen postings on LinkedIn where teams are congratulated for increasing their velocity. I’m saddened and disappointed that in 2016 we’re still talking about velocity in this way. I’m not sure what got us here but instead of simply complaining, I am compelled to share my thoughts in the hopes that it may help someone or some organization now or in the future. Paraphrasing Peter Block, start with the room you’re currently in.
First of all, let’s agree on what velocity in the context of Agile software development is. Operational definitions are extremely important and I think defining velocity will do us some good. Velocity can simply be defined as the:
Sum of effort estimates completed in an iteration (see the Agile Alliance reference for more information of velocity).
Any other usage of the term in an Agile software development context is a redefinition of the term. Agile velocity doesn’t refer to how fast a team works. It’s not even the count of items completed in an iteration (that could be throughput). It how much of our effort estimates did we complete in an iteration. No more, no less. That simple.
As the Agile Alliance article makes clear, velocity is primarily a planning instrument. Carefully read the article as it provides a pretty good explanation of the purpose of velocity and what it should be used for. Pay attention to the common pitfalls as well.
(However I must point out that many Agile teams effectively forecast and plan without using velocity. Stated differently, velocity is not a requirement for forecasting and planning.)
But maybe you still think that we should be able to use velocity to gauge how productive our team is. Maybe the information presented so far is not convincing enough for you. In that case, let’s take a moment to dissect what it means for a team to increase its velocity.
If velocity is the sum of our effort estimates, increasing our velocity would mean that we have to increase the sum of our effort estimates completed. On the surface, it may seem that this would be easy to do. All a team has to do is increase the number of items it completes and their velocity will increase. However, completing more items doesn’t assure us of a velocity increase because we can’t assume that our estimates are the same or larger than our estimates for previous iterations. In fact they could be smaller and our velocity could actually decrease and yet it would be a good thing!
For example, let’s assume a team had a velocity of 20 points in Iteration 1, which meant they completed 4 stories each estimated at 5 points. Then in Iteration 2, they had a velocity of 18 points after completing 6 stories, which were estimated at 3 points each. Were they less productive in Iteration 2 because their velocity went down? What if they completed 7 stories in Iteration 3 and each of those stories has an estimate of 1 point? Are they still less productive? How do we know?
Don’t forget that velocity is calculated using “effort estimates”. Estimates are subject to many factors that I won’t get into in this article and yet its important to remind ourselves that each iteration the team is solving problems they have never solved before. The team effort estimates could go up due uncertainty and complexity and it would have nothing to do with how productive they are.
Determining how productive a team is based on how much of their “effort estimates” they complete totally misses the point. I think Deming would refer to this as management malpractice. It’s that bad.
And yet teams can easily increase their velocity. In fact, it’s not hard at all. All they need to do is make their effort estimates larger. I’ve seen many teams do this in my career. I’m not sure your organization really wants that. Riffing off of Goldratt:
Tell me how you’ll measure me and I’ll show you how I’ll behave.
So encouraging teams to increase their velocity is simply something organizations that are intentionally adopting Agile should not be doing especially if they don’t want their teams to game the system. I will go further to suggest that using velocity to determine predictability (in the small) is in serious danger of missing the point of velocity as well. There are there better ways to do this and I will be addressing that point as I finish my series on predictability. If you missed the first two posts, check out Part I and Part II.
After all this talk on velocity, I am moved to remind us that the primary measure of progress for an Agile team (and organization) is the amount of software that has been delivered to users and that the users find valuable. All other measures are secondary and tertiary. Velocity can be used to help forecast and plan (and there are possibly better alternatives to it) but let’s not use velocity as a measure of productivity. If you must use velocity, use it responsibly.