Wednesday, 28 January 2009

Getting the measure of Value

In my previous post I made the claim that we should not be measuring velocity (to the customer at least) in terms of functionality and effort delivered but in terms of value delivered. In this post I will expand on this by explaining how value and velocity work together.

The idea behind measuring velocity in terms of value is simple and, at its core, doesn't greatly differ from the way in which we measure velocity now. Functionality is still broken up into stories (or MMFs if you prefer the Kanban approach) and they are still assigned points. The subtle change comes from what the points represent: not the size of the story but instead the value of delivering it.

The first problem with this is how to assign points of value to a story? Value is something that can be hard to define, that is variable and may be measuring different things (monetary value, visitors to a web site, time saved). Story sizing has similar difficulties so it makes sense that the solution is the same: estimation. Value can be estimated by having the team discuss a story and assign points to it. It doesn't have to be accurate - it's an estimate - but it does have to be representative and the more the project goes on the better it will get. The important thing is to decide on what a unit of value represents and as a team (customer, users etc.) agree to it. But guess what? Estimating the value of something is a core activity of most businesses and they should be both used to it and good at it to.

Which begs the question what should a unit of value be? This is highly dependent on the domain and type of business. In most domains value could simply be represented in terms of money: a story to allow people to purchase your widget online is the profit of the widget * the increase in the number of sales. In some domains it might be different, for example a web site (wikipedia for example) may measure value in terms of how many visitors it gets. Some domains may be more complex and have a combination of the two (or more): number of visitors and the money raised in advertising. In these cases the solution would be to find a common representation: maybe one visitor is worth £10 in advertising revenue (for example). Some domains may even express value in a way entirely different (schools: exams passed, hospitals: lives saved etc.). The important thing is that what the unit of value represents is consistent and meaningful.

Now stories have been assigned points which represent their potential value how does a team earn (or realize) them? If you read my last post you may remember that I started by explaining that in Lean you don't earn value until a customer receives it. This rule is extremely important and velocity should work the same way. Until the customer (or end user) has the functionality out there, working and in use the team does not get the points. Functionality not delivered, only partially delivered (delivered only to a pilot group etc.) or released but unused is not considered delivered - it is inventory - and therefore does not realize its value. Until the customer has realized the value then it is not recorded on the velocity.

Recording velocity in this way ensures that it represents the reality as perceived by the customer and aligns it with the rules of Lean. It should also change the way teams are measured and motivated: their focus switches from getting functionality out of the door to genuinely delivering value into the hands of the end user.


Anthony Williams said...

I agree wholeheartedly that the team needs to keep track of the value being delivered. However, conflating this with velocity I think misses the point.

Velocity is a measure of how much code a team can get done in an iteration, based on complexity. If a team has a velocity of 20 points/week then this means that next week you can plan to do 20 points worth of work. Of course if you choose work with no value then that's rather pointless.

By assigning a size/complexity estimate as well as a value estimate, you allow the Customer/Product Manager to pick the stories with the most appropriate value/effort trade off. Two stories of equivalent value might have vastly different effort/complexity estimates, for example.

Anonymous said...

Love it.

Only problem with measuring Value Velocity is that the velocity will decrease incrementally as each feature is delivered. Having attacked the highest value for money feature first, the value delivered will be lower and the cost higher for each and every remaining feature.

At some point, the opportunity cost of the next feature becomes so high that it becomes obvious that the team should move onto something else with higher value for money.

Whilst I'm all for this, the client is likely to find this kind of approach quite threatening. Any ideas for how to deal with this?

J said...

Getting loads of spam from this page!

Anonymous said...

Hey i just came here to let you know about a service i offer. I offer cheap backlinks that can help you website rank significantly better on Google. Traffic is everything and to get decent traffic you need to rank well in the search engines. My service can help provide that, check out my site

About Me

My photo
West Malling, Kent, United Kingdom
I am a ThoughtWorker and general Memeologist living in the UK. I have worked in IT since 2000 on many projects from public facing websites in media and e-commerce to rich-client banking applications and corporate intranets. I am passionate and committed to making IT a better world.