Defining Value

I was recently at a talk where one of the key topics was “Defining Value”. I actually felt rather prepared for it – after recently reading The Goal I was fairly confident that the goal of any business was to make money. So “Value” would be anything which either earns us revenue or aids in our ability to make money.

It sounds boring, but it’s true.

My point actually kicked off a lot of discussion, in a room of experienced developers the proposal that unless we’re earning money we’re not adding value was rather controversial “what about paying technical debt!?” was one of the initial reactions (and one we came back to very quickly).

Delivering maximum value is of course what Scrum is all about, the idea that the team is constantly working on the most valuable piece of work is key to the sprint framework. So to be challenged to define value was an interesting idea, especially when Pete (our facilitator) threw out the following quote things became interesting:

“As a general rule of thumb, when benefits are not quantified at all, assume there aren’t any” – Tom DeMarco and Timothy Lister

With paid for work the value is often clear, the work is worth whatever the customer is willing to pay for it. Again, work to generate sales the Product Owner can list the contracts which will be opened up by a particular feature if it was to be implemented.

Support work becomes much harder. We all know that it’s easier to retain an existing customer than to earn a new one and anyone in sales will tell you the value of upsell and good customer service. So how do we justify spending hard pressed development resource fixing bugs, answering questions and supporting our existing customers when it does not earn us any revenue?

We all agreed that the only way to quantify the value of technical debt was to look at how much time and effort was being spent in supporting it. If an area of your software is full of bugs and you spend four days of each month assisting customers using it then over the course of a year it’s worth at least forty eight days to improve it!

Support work is valuable because by not doing it you’re putting your customer’s loyalty to you at risk. Reducing technical debt is valuable because it makes support work easier.

The next time you’re working in an unloved area of code, don’t moan about it – measure it. Present the business case to your Product Owner and help them quantify the value of refactoring and improving the code. It will make it a lot easier to justify doing the work!