23 Points of Value Please

Author: Daniel Ginn

When I go grocery shopping I often think to myself ‘This would be a breeze if I just picked one of everything in the store, I’d never have to worry about forgetting something or having something I didn’t realise I needed. I then realise how much I have in my wallet and think ‘actually I think I’ll just get what I need’. Seems logical, so why do I still see projects with every story being a MUST HAVE. Has someone borrowed dad’s credit card?

Seriously though, the beauty of the financial mechanisms that we live with force us to make rational decisions with our money. This rationalisation disappears when we are not spending our own money. Well I believe Agile does offer some help here in the form of value points.

This concept was first introduced to me at the recent Agile Australia conference by Jim Highsmith, one of the authors of the Agile Manifesto, in his keynote address about how we measure Agile success. The idea behind value points is to assign value to features or even down to the story level using business input. The project team can then use this information to focus on delivering the highest business value features/stories to the customer.

So the desired behaviour here is – To get the business to identify what is really valuable to them. But what mechanisms can be used to encourage this behaviour? Well, Jim mentioned a couple of techniques to achieve this.

1. The first is to use true value, that is, the actual expected benefit for the productionisation of a feature or story. The problem with this is, that it requires a great deal of effort in terms of analysis, and it may not be possible on projects where benefits are not easily defined by a number.

   

2. The second method is more pragmatic and uses a relative approach to assigning value. That is, giving the customers the opportunity to assign relative value points to features or stories. By limiting the amount of points that the customer can assign, the customer is forced to consider the relative value of each story against another. The abstract value rating also allows for points to be assigned down to a story level. On smaller projects all stories can be considered together, on larger projects have the points divided at the feature level and then assign the feature level points to the stories underneath them.

You may receive pushback from the business and find that they don’t want to participate. If so, let them know that all effort must measure both cost and benefit before being scheduled, otherwise you can’t be sure that it adds value. Another method the desired participatory behaviour might achieved, is through employing gaming mechanics. This means, make a game out of the value points assignment.

In a recent project, I setup a virtual storefront in which stakeholders could go in and buy stories that were important for them. The participants had two opportunities to buy stories and could see what others were buying in between each “sale”. I think the most critical parts of the exercise though are setting the scenario, making it fun and creating the same limiting conditions that one has when grocery shopping.

Any of these methods will only be marginally effective unless useable software is being regularly released.

By having regular releases you are homing in and delivering on what is most valuable to your business. You never know, the customer might come back after a couple of releases and say ‘Thanks, but for now, that’s all we really need’.

So the next time you see a customer pull out dad’s credit card, value points might be the way to go.

---