Do we need ROI in prioritisation?

Return on investment (ROI) is a tool used in accounting to measure investment profitability but also in software development to prioritise backlog items. The idea is simple. Let's define the value that a backlog item generates, estimate the investment cost, and then we can calculate its ROI: (value - cost) / cost. When we have these for all items in our backlog, we can sort them by ROI and build the items with highest ROI first.

Where's the value estimate?

Although the idea is simple and compelling, I've never seen it being used in practice. Or to be more precise, I've only seen half of it being used. In other words, I've been in projects where the developers or other people try to estimate the time (cost) it takes to build something. However, I have never been in a project where the value estimates have been made for the backlog items with same accuracy. So, why to bother estimating the cost, if we don't estimate the value?

Probably the reason why the value is rarely estimated, is simply because it is more difficult. It's often quite easy to say that one feature is more important than some other feature and provide convincing arguments. However, saying how much more important in terms of money is much more difficult. I guess this is because features usually are a part of something bigger and it can be really hard to track their effect on revenues even afterwards.

Simplified ROI

So how can we make proper prioritisation if we don't know the exact value that features bring? One solution for this is to simplify the ROI formula. Please consider what happens if the cost is 1, i.e. if all backlog items are approximately equally sized. The formula becomes ROI = (value - 1) / 1, which is basically same as ROI = value. This means that we don't have to know the exact numbers anymore. It's perfectly fine to say that this feature is more important than some other and make the prioritisation decision only based on that.

Obviously this works only if the development team knows how to split the tasks into small enough pieces. If your team has tasks that take 1 day and tasks that take 1 month, you cannot use the simplified formula. But if all of your tasks basically take 1 day, you can just focus on the value the tasks produce.

You may say that the formula cannot be simplified like that if tasks sometimes take half a day and sometimes 1.5 days. The latter is three times compared to the former, right? But I think that in our highly variable software development context it's ok to estimate those tasks as an average of 1 day. Although we might have an idea that something takes half a day instead of one, the experience has shown at least for me that those estimates aren't very reliable. So from the estimating point of view, using the average of one day is just fine.


PS. You may want to read my comment from the comments section. It hopefully clarifies this post somewhat.