Comparing Value, Velocity and Value Velocity

Posted by Vikas Hazrati on Aug 04, 2009

Sections

Process & Practices,

Architecture & Design

Topics

Delivering Value ,

Agile ,

Agile Techniques

Tags

Value & Metrics

An implicit assumption made by most Agile teams is that 'value' is directly proportional to the 'velocity' of the team. While this may be true in some cases, however mostly, the team velocity gives little indication on the true value delivered.

Ryan Shriver suggested that value is a measure of the delivered benefits, as perceived by the stakeholders. On the other hand, velocity is the aggregation of story points that a team can deliver during an iteration. Whether all of these story points deliver value is debatable. According to Ryan, the development teams should ask the following questions,

Answer this question: What’s most important for the people financing your project-product-service? Is it the benefits they expect from the solution, such as increased revenue, market share or operational efficiencies (we’ll call this business value)?
Or is it the estimation accuracy of the team working on the solution (velocity)?

Similarly, Mike Cottmeyer suggested that value and velocity are not explicitly linked to each other. While a team may be adding feature after feature at a rapid speed, thus achieving a huge velocity. However, if the sales team is not able to sell the product or business is not able to use it then the team is actually adding little value. He also added that value for a complex product would depend on the value added by all the teams in the chain. According to Mike,

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.

So, if velocity is flawed, what is the best measure of productivity?

Kai Gilb’s suggested the role of a Value Product Owner . He illustrated how Stakeholder and Product Values can be integrated with Scrum to measure value. Here, the Product Owner plans, prioritizes and tracks results at the Stakeholder and Product value levels.

Ryan Shriver suggested other techniques for measuring value.

James Shore suggested an interesting way for measuring productivity. This is called Value Velocity. According to James,

Here's the trick: rather than asking your business experts to measure business value after delivery (difficult!), have them estimate it beforehand. Every story (or feature--keep reading) gets an estimate before it's scheduled. At the end of each iteration, add up the value estimates for the stories you completed in that iteration. This is your "value velocity." It's like traditional velocity, except it's based on your customers' estimates of value rather than your programmers' estimates of cost.

Thus velocity does not always reflect the true productivity of the team. The key is to measure value delivered and make concrete efforts to improve on delivering higher value than velocity in every iteration.

 

1. Back to top

   Confusing Velocity With Output

   by Siddharta G

   A lot of people get confused over velocity. Velocity is for measuring iteration capacity for planning the next iteration, or looking forward in the backlog to see which iteration something is likely to get scheduled. Thats it. Reading any more meaning into velocity it flat out wrong.
   
   I've seen teams use velocity as a measure of value, productivity etc etc a whole lot of other metrics for which velocity is a convenient number to use. It is none of these. If you want to measure productivity, look at cycle time instead.

   Reply

• Older >