Early Release

There is a time value to money. A dollar today is, theoretically, worth more than a dollar tomorrow because we can make use of it. If we invest it, then it becomes more than a dollar. We might not see that value in a single day, of course. And we might not take advantage of having the dollar in our pocket. If it just sits there, unused, we’ve squandered that time value.

What happens, though, if you release a little bit of new functionality and it starts earning a little bit of income while you continue to develop the rest of the functionality you ultimately want? You’ll still be spending for development at the same rate, but a tiny bit of that cost will be offset by the value earned by the early release. If you keep doing that, the functionality grows and so does the rate of early value. That is, the rate of value grows if you take advantage of it, and don’t just keep it in your pocket.

Let’s compare the differences between waiting until you’ve built “the entire thing” before putting it in production and releasing incrementally as you can gain value. What’s the estimated income from “the entire thing?” If you wait until a final release, you’ll spend for development until that point and then start seeing that income.

If you can release something valuable earlier, you can estimate you’ll earn a small portion of that income sooner. Each time you release, you presumably increase the amount of current income from the project. By the time you build “the entire thing,” you are earning the same income as if you’d waited to release. The current net cost, development costs minus current income from the project, decreases over the life of the project. The accrued value doesn’t go as far negative and reaches the break-even point earlier as shown in the figure.

It’s possible you’ll reach a break-even point before you finish developing. The income might become more than the cost of development, and the project becomes self-sustaining. If this is the core of your business, that’s exactly what you want. This lets you continue to develop revenue-producing functionality forever. Even with very conservative returns on a fixed-scope project, delivering some functionality early and starting to accrue some value from it makes a considerable difference in the time to a break-even point.

IT projects can also accrue value earlier. Even when there’s no customer paying money, presumably there is benefit in the new system or the project wouldn’t have been undertaken. Perhaps there are cost savings from the new system. It may be easier and quicker to do some type of work, or the operation and maintenance is cheaper or easier than an older system that is being replaced. Perhaps the new system provides the capability to do some work that wasn’t previously feasible. It may be harder to quantify the value accrued when it’s not income, but it’s still accruing value.

Minimum Releasable Value

Ryan stood in the hallway looking at the whiteboard with the big BurnUp Chart. Sidney walked up and asked, "What are you thinking?"

"I’m thinking about the order of these features, and what it would take to start seeing the value before it’s all built."

"Great! Would you like to change the order?"

"I’m thinking that we can put a limited version of this new call center into production with just a single division, and we won’t need all the features. If we direct only the customer service number of the Applied Magnetics division, we won’t need any of the advanced call-routing features. Their call volume is low enough that they don’t use the Interactive Voice Response feature. And the customer search feature on the agent console will be good enough for now."

The two of them started moving cards as Ryan talked. They moved everything that Ryan thought essential downwards and filled in the space above with the cards they’d taken off to make room.

Ryan stepped back with a look of satisfaction. "I think that’s better. I’m looking forward to seeing it actually used."

Sidney replied, "We can always change it again. But looking at it now, it looks like approximately three more months to that minimal releasable version. Thanks for your help."

Ryan looked up. "Thank you. It wasn’t like this when we built the last system."

Releasing multiple times throughout the project effectively turns it into a series of mini-projects. Each of these will have a release date that will interest someone, and they’ll want to know when that is. We have an advantage, however, in judging these interim release milestones. As when you are Chapter 4, ​Checking Progress​, you have some recent historical data with the same context as you’ll have going forward. Earlier milestones give feedback on the validity and accuracy of assumptions made in estimating, and that feedback will help you correct estimates of future milestones.

Deciding to release early is one reason to look at milestones prior to the end of your project, but it’s not the only one.