What’s it worth to you?

Tom Breur

31 August 2014

A friend of mine recently asked me: how do you determine the value of software? My answer on Twitter was succinct (as required in 140 characters) and pretty straightforward: “cash is king.” A customer’s willingness to pay for it, imho, is (still) the best yardstick to measure value. Needless to say, there is some more to it than just that. But in a way, it is interesting how the brevity of messages on Twitter “forces” you to go straight to the heart of the matter.

I use a very simple approach. I just ask: “How much are you willing to pay for it?” Although truth be told, many features are born out of necessity (compliance, risk management, etc.), so when the contexts demands this, I’d ask “How much would it cost (would be at risk) if we didn’t have this?”

If my business partner finds that question difficult to answer, then maybe he needs to clarify his business case. We don’t work in a vacuum, and sometimes need to confer with a broader group of stakeholders. Either way, at this junction it seems that the bottleneck for setting priorities is determining value, which is, and always must be owned by the Customer’s (in Extreme Programming, XP) or Product Owner (Scrum). But most customers could do with a little help estimating value.

Every system (as we define systems in the Theory of Constraints) has a bottleneck, and the throughput (“Velocity” in Scrum) of the system is limited by the bottleneck. By working with the customer to determine value, we’re effectively swarming together around the bottleneck (setting priorities) – allocating everything we have in the team to enable maximum “flow” there.