This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Comparing Agile Value and Velocity
Is there a difference between the value an agile team delivers and their velocity? Said another way… if I increase the velocity of the team… aren’t I getting more value from them over time? Like so many things we talk about here… the answer really depends on your context.
Is there a difference between the value a team delivers and their velocity? Said another way… if I increase the velocity of the team… aren’t I getting more value from them over time? Like so many things we talk about here… the answer really depends on your context.
You might be inclined to make the argument that velocity is really just a measure of how many story points the team can complete in a given iteration. There is no explicit dealing with value… only relative size. But… if the Product Owner is prioritizing the backlog… and asking the team to deliver the highest value features first… isn’t there an implicit correlation between value and velocity?
My take is that there is a correlation between value and velocity at the team level… it is when we get beyond the team that relationship starts to break down.
Think about this scenario… let’s say them team is cranking out feature after feature… adding great stuff to the product… their velocity stabilized a few sprints back and is getting better and better every iteration. The company has a great product but a terrible sales team and even worse marketing. While the product is technically superior to their competition… how valuable is it if no one buys it?
You might make the case that all those really cool features ended up having very little value to the market. Great velocity… not so much value.
Here is another scenario for you… let’s say you have four teams that have to work together to deliver a new product suite to the market. Teams A, B, and C have fantastic velocity but team D just hasn’t been able to get their stuff together. Team D ultimately delays the release… and the overall product is late to market. In the meantime… the competition just released the latest version of their product and yours doesn’t do so well.
How much did the velocity of teams A, B, and C help the overall value of your product? Again… great velocity… not so much value.
Okay… last one. Let’s say you have 7 component teams that have to deliver features into several major architectural sub-components. All the teams are rockin’… they have met all their high level milestones… they know where they need to take their part of the project. One of the teams realizes a significant risk and their velocity tanks. The rest of the teams keep going… they are building great stuff… stuff that certainly has to be built someday… but again… that one team causes us to delay the release.
Most of the teams were doing great… one team not so great… where did all the value go?
Lean tends to take a broader look at value delivery across the entire value stream… across the enterprise… Scrum by it’s very nature tends to look only at the delivery team. So… at the single team level… you can make a great case that there is a correlation between velocity and value. It’s an implicit link, but it is there. When you start looking outside the team… across the entire value stream… that is where the correlation between value and velocity starts to break down.
When the Lean folks say that Scrum focuses on velocity and Lean focuses on value… as I see it… this is the reason why.