Time-Value profiles and inverted estimation
Allan Kelly, allan@allankelly.net
If you go to Agile events or read Agile blogs and journals it isn’t long before you hear about “Cost of Delay” or “Opportunity Cost of Delay.” Although this idea is well known in Agile circles it is little known outside of Agile circles and many people find it confusing.
The name “cost of delay” tends to lead people to think about extra costs incurred because something is delivered late. For example, using express shipping because manufacturing is late. But extra costs (a form of waste to lean thinkers) are often dwarfed by revenue and profits foregone because a product is not in the market earlier.
Revenue lost because products are in the market earlier is often invisible because it was never seen in the first place. Cost of delay includes such things as sales that don’t occur because the customer finds an alternative solution, sales lost because some critical date (like Christmas) gets missed and sales lost to rivals - retaining such sales is sometimes called revenue protection.
And of course, if you spend less time developing a product there is every possibility that the costs of product development will be lower too.
Yet I find the concept of cost of delay from any of these sources is just too abstract for most people. This changes quickly if you write a number - almost any number! - on a story. Say you write 10,000 on a development story and say “this story is worth 10,000 if we deliver it tomorrow.”
Next you can ask, “If we deliver it a week later is it worth more or less than 10,000?” The answer is usually it is worth less, which allows you to ask “How much less?”. Say the answer is “Just a bit less” you might write “+1 week: 9,750”.
You can repeat this process for different intervals, say one, three and six months, a year, two years. That allows you to construct a graph which I call a Time-Value profile, shown in the first diagram.
==> picture [421 x 266] intentionally omitted <==
Time-value profile for a Santa Clause app
A time value profile shows the total value for a given piece of work at different points in time. As such it shows visually how value change over time. This graph is useful in itself but it can be even more useful.
Milk again
If you pick up a carton of milk you will find a “Use By” date. This is the date by which the producer thinks the milk should needs using by. After this date the milk might be off and should get thrown away. In our terminology: it becomes valueless.
Some foods have a “Best Before” date. Such foods loose much of their taste and goodness after this date. Again this is subjective and set by the producer but it is a guide which says “After this date the product isn’t going to give the same benefit as before the date.”
Adding “use by” and “best before” dates to the time value profile produces the second diagram. Again both of these are judgment calls but by having the discussion about such dates one can build shared understanding.
==> picture [421 x 267] intentionally omitted <==
Santa Clause app with best before and use by dates
Seeing changes things
Armed with this information ones view of the world changes. The highest value business story might not be the one to do first if the “best before” date is some way off. Another, lower value story with a closer best before date might be the one to do.
Projects are little more than a bundle of deliverable items. Different items can often have different time-value profiles. Rather than aiming to deliver the whole project at by one date it makes sense to deliver increments in the order which they maximize value, those with rapidly falling value should go first.
A project waiting to start might contain items which have a high time-value dependency. Failure to deliver these items soon might loose significant value and it may well make sense to deliver these items as soon as possible, even before the final items of the previous project are complete.
Engineers can consider what they can build in the time available. In a market with a time critical date, like the end of the tax year it can make sense to build something smaller which enters the market sooner. Building something with less functionality, which goes on sale sooner and only captures a small part of the market may well deliver higher revenue than a larger, more functional product which enters the market later even if the larger product captures a larger percentage of market share.
Similarly in a rapidly growing market entering sooner with a smaller product might give first-mover advantage. But in a growing market where first-mover advantage has gone entering later with a more functional product might be a better strategy.
Inverting estimation
In fact the whole basis of estimation becomes inverted. Rather than estimate how long work will take to complete it makes more sense to estimate the time-value profile and determine what work needed going. Engineers can then work backwards within these constraints to determine what to build in the time available.
Engineers faced with a three-month window of opportunity will plan and build a very different product to engineers faced with a 12 month window. Knowing the engineering options and the time-value profile allows engineers and business representatives - be they product managers, analysts, or others - to have a meaningful conversation about options and value over time.
Yesterday
Time-Value profiles also help with the old “I need it YESTERDAY” problem. If the need was yesterday, and the need has gone, then the time-value profile shows no value for today.
==> picture [421 x 286] intentionally omitted <==
- “I need it yesterday” Time-Value profile
If all the value accrued yesterday then, in the absence of a time machine, delivery tomorrow (this earliest possible delivery date) is valueless. But in truth, most “Yesterday” demands still have value tomorrow, and the day after, they may well look different:
==> picture [421 x 286] intentionally omitted <==
Revised yesterday Time-Value profile
One doesn’t need a time machine to when presented with such a profile.
Deadlines are elastic
Once you have a time-value profile for a feature or product it becomes obvious that deadlines are not binary all-or-nothing events. Deadlines are elastic by value - delivering your product on different dates results in different outcomes, different values, different costs and revenues.
There are genuine trade-offs to be made between how much product is built versus how much of the market is captured. This needs to be a discussion between those who understand the market and those who understand the technology. Knowing the time-value profile is can help expose some trade-offs.