Velocity: what flavor would you like? -- part 2 in a series
M_Kevin_McHugh 270001CDK4 Visits (4070)
Target roles: Product Owner and Scrum Master
Let's talk about the flavors of velocity and the term 'velocity' itself. Complexity, Value, Risk, and ROI velocity are all important ways to understand how a team, sprint, and release are performing for the Product Owner.
Here is part of the Product Backlog:
Defined to mean the average of several velocity measures of the same type. It does equal the total contributing points / sprints. But, the second method is less useful, as we will discuss in later articles. As you can see
So much for what these things are. Next, let's also look at how these three velocities interact and how we can use them to make fact based decisions about managing our projects.
Complexity Velocity should be a relatively stable line across the chart. And, since we employ a packing algorithm to assign stories into sprints, it will nearly straight. The variance comes in when we can exactly pack the sprint with points. The fact that assignment of stories into a sprint is a packing problem means that we can automate story assignment into a sprint. For more on packing problems, I've provided a link to Wikipedia on the topic: http
In all cases, we pack according to story points and Average Complexity Velocity because this is the team's ability to product work units. It is steady. This is a straight Agile behavior. Keep doing it.
So, what is the point of all this if we are going to continue to use Complexity Velocity for sprint planning. Well, ... this is not an article aimed at the Team role. It is aimed at the Product Owner role. The product owner can choose to prioritize based on Value, Risk, or ROI. Let's look at those choices.
PRODUCT OWNER SORTING CHOICES:
Value Velocity indicates how much value we gain each sprint. One would think that this should be as high as possible. But, that's not true. Think about the situation where we can get a billion dollars in value from a sprint. Yes, I meant to use a "B" to make a point. However, the cost to get the billion dollars is 2 billion. Is that worth the effort? no.
SORT BY VALUE:However, value is important. How would we use it? Well, if we don't have ROI, then use Value as the means to set the ranking/priority for stories. In other words, sort by Value. This will cause high value stories to be included in earlier sprints. It will happen automatically when we pack stories into the sprint.
SORT BY RISK:
Risk Velocity is a complex issue. I've been exploring / modeling what happens when risk value and value are added together. The implications are not entirely clear to me. Also, risk relates to value and Net Present Value in other than straight arithmetic ways. so, my recommendation is this. Use the risk reduction amounts to juggle prioritization. Listen to the team when they need a risk reduced. If the risk isn't highly valuable, then either the team's sense is wrong, or the risk mitigation amount isn't well enough understood.
I would also suggest that it is less straight forward to adopt a risk velocity. So, for an organization undertaking change, I would treat risk as an adjunct to value. Try to drive it down. But, make this a secondary adoption goal.
VELOCITY AT THE RELEASE LEVEL:
I also looked at the accumulated numbers across the whole release which has six sprints. Again, to my surprise, and perhaps due to random numbers, the model shows that sorting by value provides the best ROI for the release.
Release Value when the stories are prioritized by Value, Risk, or ROI...
Release ROI when the stories are prioritized by Value, Risk, or ROI...
Velocity is a misnomer. Complexity Velocity is really more like Horsepower. Power = work/time. Power = "story points accomplished" / sprint duration. I have not completely explored the implications. First, I would need to look at the translation of "work" to "story points accomplished". That looks like a fit. Then, I have to ask of the units of the horsepower formula translate. Then, where else is the "power" term used in physics? Torque doesn't seem to fit since there is no fulcrum around which to pivot. But, mass and acceleration might fit. We often speak of bringing things "up to speed". Wouldn't it be fun if some of the physical world formulas gave us more insight into building software and systems?
*Notes for the model: I held the team size, time commitment, and skills constant and the sprint length constant. In the modeling I use for the charts above, I did not attempt to correlate complexity to value. I also did not attempt to correlate complexity to risk. Intuitively, I sense that there is a correlation. I may extend the model at a later date if it will provide me value for a later discussion.