Measuring business value for software development isn’t easy. Point in fact it’s rather hard to put a quantifiable measurement on something that simply doesn’t have a quantifiable metric tied to value in it’s life-cycle. This article by Kelly Waters notes that sometimes it’s painfully obvious what the value is to the business (in the case of developing a new software package for sale, for instance), but more often than not the measurement is ambiguous or non existent. How does one get measurement on a team that addresses bug fixes, user requested enhancements, or new features? Waters suggests using Fibonacci points (where a series of numbers where the number is the sum of the previous two (1,2,3,5,8, etc.)) to assign business value and size of the project: The development team provides the points for size, because only they are qualified to judge how big a feature is, relative to another. Whereas the business value points should come from the Product Owner/Business Owner. In the same way as the development team estimates in points, the Product Owner decides on a business value for each item, relative to each other. The key thing here is that the estimated business value is relative, i.e. a feature with a business value of 2 is twice as valuable as a feature worth 1; a 5is worth 5 times a 1, etc. Using the Fibonacci score, a calculation could then be done wherein the business value is divided by the size, you can come up with a scale of priority, which Waters calls the “priority score”. Waters is the first to point out that this is a rudimentary way of determining the business value of software development in Agile, but it still might be worth a shot if there are no current measurement systems in place.