BT

Your opinion matters! Please fill in the InfoQ Survey!

Comparing Value, Velocity and Value Velocity

| by Vikas Hazrati Follow 0 Followers on Aug 04, 2009. Estimated reading time: 2 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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.

 

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT