When did Dev Teams decide velocity is a direct measure of productivity?
Before we start, let’s define productivity. Productivity, in the software world, is the creation of software features that contain a level of Business Value to an End User or Customer where the higher the value of the Business function to the Customer, the higher the perceived level of productivity.
This subject is actually very complex. This article is an attempt to get to a base understanding using simple metaphors.
There has been talk lately in the Agileverse that seems to equate measurement of velocity with the measurement of productivity. While I admit there is a relationship between the two, it is not a direct relationship. In other words, if Sprint 3 delivered 45 points of velocity and Sprint 4 delivered 45 points of velocity, you can’t say that the productivity delivered in Sprint 3 is exactly the same as Sprint 4.
Let’s look at a simplistic example.
I (the Owner) have a pile of Field Stones (my Backlog) on the left side of my yard that I need to move to the right side of my yard. The value for this example is simply to get the Backlog items (stones) to the other side of my yard. I can carry 45 pounds of the stones in my arms. Each trip of 45 pounds of stone has the same value (productivity) because the content is the exact same. If I go buy a tool (two rugged sacks) I can double my velocity to 90 pounds of Field Stone for each trip. Yes, I’ve doubled my productivity, but that’s an outflow from the fact that each trip carries the exact same thing (Field Stones) so the value of each trip is the same, 90 pounds of Field Stone. I have no choice for a trip with a different value.
If each trip is an iteration, then the velocity of each is the same, 90 pounds. The “productivity” of each trip is the same as well because the content of each trip is the same.
Let’s add differing content to the Backlog.
But again, the value is simply in the movement of the Backlog items, nothing more.
Let’s start over. This time, I have a Backlog of a pile of Gold Bars, a pile of Field Stones and a pile of Silver Bars on the left side of my yard. My Backlog has items of differing values so now I have to make a choice for each trip/Iteration. To me, the Owner, Gold Bars are more valuable than Silver Bars, and Silver Bars are more valuable than Field Stones. If I use Trip #1 to move 90 pounds of Field Stone, you could say it could have been “more productive” if I had carried 90 pounds of Gold Bars instead.
Given what I value, the most productive delivery plan would be to deliver all the Gold Bars, then all the Silver Bars and then all the Field Stones. But I could deliver all the Field Stones, then all the Silver Bars, then all the Gold Bars, even though that wouldn’t be as productive.
For each trip/Iteration:
The velocity is 90 pounds each trip. That is a hard fact.
The productivity is dependent on the content of each trip. A trip of 90 pounds of Gold Bars is more productive than a trip of 90 pounds of Field Stone. We don’t measure this currently; we trust the Owner (the person directing the work) to make the most productive decisions for each trip/Iteration.
There is a similarity here to the Chaos Study produced by The Standish Group.
Not all Software Features are equal. Some are used more than others, some generate revenue while others don’t, and some have more strategic value than others.
Wouldn’t we be more productive if we delivered the Always Used Features before the Never Used or Rarely Used Features?
A new example that adds “context” and “content” to the Backlog.
Context matters. The previous examples only valued getting the Backlog items (Bars and Stones) from one side of the yard to the other.
We valued the activity of moving a stone or bar, not the use of it in building something usable which is a much more realistic metaphor.
Let’s start over with moving a pile of Gold Bars, a pile of Field Stones and a pile of Silver Bars to one side of my yard. However, this time the “value” isn’t in these items or even in their movement; it’s what I, the Owner, want to be made with those materials. My vision is to build a garden that contains food and flowers. But the garden needs to be protected because I have rabbits in my backyard. The Gold and Silver Bars will be used to create Garden Gnomes.
In planning out my Release Trips, I need Field Stones first because my highest value is a Field Stone Garden Wall that will protect my plants from the rabbits. I don’t need Gold or Silver Bars at the beginning because those will be needed for my Gnomes, which while I desire to have them, their value is much lower than most of the other Garden Features (the Wall, Flowers, Vegetables, hoses, tool shed, etc.)
If I move the Gold and/or Silver Bars to the early trips, I am reducing the productivity of the early trips which would result in pushing out the completion of the Garden Wall of protection and the planting.
But each trip brings over (yep) 90 pounds of Bars or Field Stones (assuming we can make something from them), my velocity.
Summary
Productivity combines two items: 1) feature prioritization choices by the Owner considering both the content and context contained within the Backlog of Features and 2) the Team building and delivering on those Feature choices in the priority set by the Owner.
“Velocity” only considers #2, the items the Team can build and deliver in a specified period of time.
Associating this to User Stories: Just because we point the “size” of a User Story as an 8 (for example) doesn’t mean the Productivity of that User Story is an 8. The 8 is simply the Story “size”. I can have a Size 8 Story that is used very often and generates revenue and I can have a Size 8 Story that is hardly used at all and generates no revenue. The productivity of those two features as relates to the Product is not the same so we can’t use this same number as a measure of both Velocity and Productivity. Let’s not forget that.
You can’t have Velocity without Productivity BUT Velocity is NOT a direct measure of Productivity.