Skip to content
August 18, 2014 / KaTe

The Sarcastic Business Value, Money and Homer Simpson for Development Teams

Price is what you pay, value is what you get.

money

This V-word will be your partner throughout your Scrum life. Get acquainted.

What’s business value? It’s the quantification of the goal your customer wants to reach with the product you’re building. Basically it answers the question: what for?

It’s amazing how often people don’t pay attention to this. And that’s where the statistics of 35% of requirements changing and 65% of functionality not being used (or barely) come from. You might have noticed that these two numbers add up to 100%. So what the heck are we building?

The problem lays in the fact that the only measurement used nowadays is money. And since software is intangible you only know about its quality when something goes horribly wrong. With cars for example, estimating the value you get from them is relatively easy (even if the seller isn’t completely honest with you) – you can see how they’re made, how much the gearbox is screeching, it it’s big (or small) enough, if it has the right mileage and you can check the opinion of the model with other drivers. You can easily say if you’re willing to pay the price for this beauty.

Would you buy a $100 car with beautiful outside, but with no engine and lacking a couple of front seats? Unless you need it for body part reselling, you will probably choose a $10 000 car with good engine, comfy seats and reasonable fuel consumption (or fun factor). So you’re willing to pay for quality. Or you’ll pay twice.

What usually happens in IT is when you’re gathering requirements, you tend to get as much as possible in fear that if you don’t – you will never be able to get them. That produces quite a lot of waste. You also wouldn’t buy a car that has everything in the world. That makes it ekhm… Homer-Simpson-like?

homer's car

So how do you measure Business Value?

Your Product Owner is responsible for that. There is even a required column in your Product Backlog that should contain Business Value. If it doesn’t – bug your PO for it.

Sometimes you can measure Business Value directly. If you’re making a system that will speed something up or save money, you can get the exact value it will bring and put it in the Product Backlog.

But if you don’t have that kind of luxury, your PO can estimate it. In some abstract scale – it can be something like Story Points for business value (your PO and stakeholders can play Planning Poker to get it) or completely abstract things like materials, t-shirt sizes, fruit etc.

Oh and one small thing. Paying back your technical debt has NO VALUE. It’s paying your loans, it doesn’t bring you joy.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: