Cost Value Curve

Reading about Kanban, I've stumbled on this nice article on scrum and kanban in gaming industry by Clinton Keith. I know that the gaming industry is very different from other software industries, but since the author is very good at pointing this out and stressing the specifics of his industry, it's not a problem. So, it's a very good article, which I recommend.

But I did react to this simple diagram. It states that you come to a breaking point where added costs don't add so much more value to the customer. I believe that it is somewhat true, but there is a greater challenge to the product owner than just spotting the breaking point. All costs are not created equally.

Que?

No, what I mean is that if you have a functionality X with the requirements A, B, C and D which for just simplicity reasons are as costly, they probably do not add equally value to the customer. It might be that D is what makes it all worth it - for the actual user. I've often seen projects where the thing that makes it all worth while is cut. "Now we've spent enough on X so D have to wait".

And more often than not D is not the most costly feature. More often it's the feature the less vocal user identifies but does not stress enough. And not seldom it's the stuff you hear responses like "well, they'll get used to that" or "it's a learning issue" from someone who does not understand why this is important. And it's often the stuff that when you do implement it is hardly noted since it is taken for granted. So we return to expected behaviour. D is the stuff which makes X have an expected behaviour.

So how do you work this? Well, one method used by for example Mike Cohn is that when you calculate business value you don't just calculate how much value a feature introduce, you also calculate how much it costs when it's not included. D might not bring so much business value but it costs a lot if it's not implemented. I think this is one of the best methods to give room to usability issues. For more on this subject I recommend Agile Estimating and Planning by Cohn.