Skip to content

Value Points: Estimating Business Value

Estimating Costs vs Benefits

There has been much talk about “business value” and “business impact” in my world recently.  In my experience, the cost part of a cost benefit exercise is often painful.  However the bigger issues tend to be around the benefit part.  Teams may end up with a prioritised backlog that reflects value in some way, but rarely do you see that value quantified in any meaningful way.

Having been beaten up for years on development estimates – both for not having them and then when we do have them for them being wrong – it seems that asking for business value estimates is the perfect riposte to being asked asked for development estimates.

This got me thinking.  People are uncomfortable giving dates presumably for similar reasons as to why people are uncomfortable giving pound based benefit estimates- we don’t trust ourselves to estimate accurately.  People are bad at estimating.

Now some years ago, some clever people came up with the concept of story points on the basis that we are better at relative sizing than we are at absolute sizing.  The rest is history.  We can calculate velocity for a team to give us a better idea of how much work a team is capable of in a given time period.  We can adjust our forecasts based on actual outcomes by using simple tools such as a burn up chart.  We can identify throughput issues with burn down charts.  If we like, we can use fibonacci numbers as they appear to reflect reality a bit better.  We can even use story points to determine when something is too big and break it down if necessary.

Value Points

So is there something similar we can do on the business benefits side?  Maybe.  Let’s think about something I am going to call “Value Points” for want of a better term.  

When thinking about benefits, let’s pick a notional story or piece of work as a benchmark for some relative sizing.  As an example let’s say building a flux capacitor will earn us 5 value points.  Then my De Lorean story, we think that will deliver twice as much value, so let us say that it will earn us 10 value points.

From here we can apply all sorts of our agile sizing techniques.   Let’s try some examples.

My Time Machine story – I think that is going to deliver 25 value points.  But hang on a second, that sounds really big.  Can we break that value size down?

Some of the team have created a value burn up chart that give us a projected idea of value points we think we can earn before the end of the year.  However mid way through, the markets suffer a downturn.  But our burn up chart adapts easily as it is based on relative sizing – we can easily adjust our projections based on actuals.    Our De Lorean work will still earn twice as much value as our flux capacitor work, just so happens that the total financial value will not be as big as we thought.  

At the beginning of the year, we have a session to work out how much money we are going to make.  Let’s get all of our stories and epics together and relatively size them by placing those of similar value into the same bucket.  And then calibrate each bucket.  Let’s sanity check what is in each bucket.  Do we really think they will achieve the same value?  And do we really think stories in the 10 bucket will earn twice the value as those in the 5 bucket? 

Finally for now, if we are so inclined, we could use Fibonacci here.  As value gets larger and larger, it gets harder to distinguish between a 100 value point and 101 value point story.  So why bother, let’s call them 100 each.

And then vitally, in the same way we can use velocity to tell us how we will progress through a backlog over time, we can use a similar concept to tell us how we will earn revenue over time.

I’m excited about this.  I feel that I could pretty much go through an agile text right now and swap story points for value points with the ideas still holding up.  So I may revisit this topic.  I am fairly sure that all the bad things about story points apply to value points too.  For example, teams gaming the system, difficult to compare value points across different teams is am issue.

A few last things to consider before wrapping up

Taking this further, it feels like there is something we could achieve by bringing story and value points together.  Maybe to tell us whether something is worth doing and if so when to do it.

Secondly, there is an area that I am struggling with a bit.  Maybe we need another dimension for value points.  Value can be earned gradually over time or it may be delivered in one massive chunk.  Even in the latter case that chunk may be delivered early or late after a change.  And does that influence when we might want to do something.

In my examples above I used value points as a proxy for revenue in the same way that some will use story points as a proxy of duration.  However, others may use story points as a proxy for complexity.  So we do not have to tie our value points to financial income.  We could tie them to the number of subscribers or cost savings.

Finally, we have those brilliant tools “definition of done” and “acceptance criteria” that help us know when we are really “done” and the story points have been earned. How easy would it be to fit these tools to value points?

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *