One thing up front: Estimating business value is hard! But definitely worth the labour!
In our current first attempt we try to bring it down to one single value: Money.
- You have to bring it down to a single value anyway.
- Money is a universally understood concept.
- Some things are quite easy to estimate (e.g. an automated process step, a performance increase which reduces waiting time)
- You can calculate if and when a feature amortizes itself during its expected lifecycle.
- Some things are hard to estimate (refactorings, security measures, additional logging capabilities, etc.)
- How do you assess features which enable the user to do things he couldn’t do before (i.e. when you cannot calculate some saving)?
- How do you assess things that just annoy the user?
Other methods (which we’ve only learned after starting to estimate in terms on money) incorporate more dimensions. This allows you to eliminate most of the above disadvantages by just creating a dimension for every important aspect (code quality, performance, security, …) that is part of the business value. The different dimensions can then be weighted by their current importance (e.g. security is not that important at the moment, but will become more and more important in the future).
We’ll see how far estimating business value in terms of money takes us, with an open eye towards other methods, but the take-away is:
Do estimate business value! And use it to prioritize!