There is more to calculating ROI than a simple equation. It can be affected by risk, time, and other factors—including whether your team is agile. Releasing software immediately after coding and testing accelerates feedback cycles, minimizes the cost of delay, and increases return on investment. Allan Kelly tells you how.
Some people love to talk about return on investment; some people hate the idea. Either way, it’s definitely a misunderstood subject.
Let’s start with the basics. Return on investment is often calculated simply:
ROI = Net Return / Investment
That is, the gain of an investment minus the cost of the investment, all divided by the amount invested. For example, if I invest $1 million in a software team and then receive $1.1 million, the net return is $100,000 and ROI is 10 percent.
ROI = ($1,100,000 - $1,000,000) / $1,000,000 = 0.1, or 10%
Easy, right?
Well, not exactly.
More to Modeling and Calculating ROI
Other possible uses for the money play a part in the ROI calculation. If the same money could be nice and safe in a bank, earning, say, 5 percent a year, then ROI is really just 5 percent (10 percent minus the 5 percent a bank would pay). Risk plays a role, and the risk-free option provides a baseline.
Financial experts normally “discount” returns against a very safe investment, typically government bonds. So, any investment should represent a return greater than that which simply lending the money to Uncle Sam would make.
To complicate matters, although interest rates are often stated in annual terms, interest payments on savings accounts are usually made monthly. Thus, calculations should be modeled on a month-by-month base.
(To complicate matters further, there are different ways of modeling and calculating the return on investment. I’m sticking with NPV—net present value—here.)
Suppose a company invests $83,333 per month in a software development effort for a year—a total of $1 million. In the final month, the team delivers a product worth $1.1 million. Because some money was spent a whole year before the investment paid off, the calculation changes: The actual return is 7.3 percent, or $73,000 net.
So time can reduce the rate of return. This in itself is an argument for developing software faster and delivering sooner—something I’m sure many developers are aware of.
But this logic also plays into the agile way of working. Consider again that development over twelve months. Imagine instead that the team made monthly releases and deliveries. That is $91,666 each month for twelve months. Now the return jumps to $97,300, or 9.73 percent. If delivery moves to weekly releases, the return sneaks up a bit further.
Next Stop: Continuous Delivery
The arguments about delivering in iterations are well established, but they tend to center on feedback cycles—how releasing software earlier creates feedback and accommodates changing requirements better, and how such cycles reduce risk because teams can make corrections during development.
Focusing on feedback, changes, and risk reduction misses a more important element: Regular deliveries can actually increase the value—the return on investment—from software.
Forget whether agile or waterfall is right for some project or another; instead, ask whether you want to increase the ROI.
There should be only one answer to that, and then continuous delivery becomes the obvious next step. Releasing software immediately after coding and testing are complete accelerates feedback cycles, minimizes the cost of delay, and increases return on investment. What’s not to like?
Value-Based Prioritization
Projects often can get stuffed with irrelevant additions. Perhaps some requirements are in there to ensure a particular executive agrees to the project. Leftover requirements from a previous project are probably there too, and some get added because people know how difficult it can be to get work in later.
Considering a project as a singular, whole, atomic, all-or-nothing endeavor prevents teams from streamlining work. Simply by cutting the low-value stories, teams can improve the project’s ROI. Traditionally, a project gets treated as a collection of requirements forming a single unit—perhaps even a single delivery—directed at unlocking some business benefit. But giving individual stories value helps you prioritize and see where unnecessary work can be cut.
Once you apply cost of delay, ROI calculations that respect time, and continuous delivery, the project model itself starts to break down. For example, suppose your team is working on a project and uses cost of delay and ROI to choose the work to do next from the project backlog and delivers it as soon as it is ready. After a while, the value of the items being done will fall off.
Theoretically, sticking with the project requests does mean teams will see the value delivered per release decline as a project progresses. The highest-value stories get delivered early, leaving low-value stories for later releases. However, in practice, teams will embrace new requests through scope creep that generate more value, and thus deliver relevant, valuable work throughout the project’s lifecycle.
Story by Story
Teams can boost ROI far higher if instead of considering the ROI on a project level, they consider value, ROI, and cost of delay on a story level. Projects are simply big bundles of stories that arrive at the same time. If you add value, ROI, and delay analysis to each story in the bundle, you can increase the value of work.
The challenge is to adopt new approaches that allow teams to think of work in small, individual pieces. This will require a mind shift, but it’s worth it when you consider how much it can maximize project value.
