Use Cost of Delay to See Value

One way to define the value for the work is to make sure the work is still valuable. Use the ideas from cost of delay to define the value now and in the future.

You may understand cost of delay without having known the name for it. Cost of delay, as illustrated by the diagram, is the cost you incur from not releasing the work when you want to, and the implications of that delay on future revenue.

There are four potential costs when you delay work:

• The company misses the potential sales from the introduction delay.

• The delay introduces lower maximum sales.

• The delayed introduction creates less overall demand, so the feature has less value in total.

• With less demand, the end of life might be earlier with a delay. Often, this is a function of not being able to capture the market at the optimum time. Since you don’t have the customers, you have an earlier end of life.

Here’s a quick example. Imagine you’re working at a game company. Game companies make most of their money when people buy presents for Christmas. When you release a game before October, you make the maximum amount of revenue, because your game is available when the buyers want it. If you release the game in October, you may have lost some buyers, because some people buy their holiday presents before then. If you release the game in November, you will still capture some buyers, but some—even many—of the potential buyers have already bought their presents. If you don’t release until December, you’ll have lost most of the buyers. If you release in January, no one will care. And if this is your first product release, you might have to end-of-life the product in January because no one cares enough to buy a follow-on release.

The real question is this: When is the “best” time to release this feature (and, by extension, the project)?

Estimation often assumes that the feature has the same value over time. However, if you miss a specific time, the feature often has a decreasing value over time.

Thinking about when the feature no longer has value is one way of articulating value via cost of delay: When does this feature no longer have any value? When does it have maximum value to us? The diagram shows how you might graph the value over time when a feature (or release) no longer has value.

In this case, the release has the maximum value anytime through September. Once we get to October, the release loses at least half its value. By December, there’s almost no value.

Although I’ve discussed the value of a release, you can use the same idea for features. Does your product need a way to send and receive email now? If so, you might not need to forward email or cc email immediately, but sending and receiving is something you need to do now.

When you start to break apart a feature set into features and use the value-over-time idea to rank the stories in a feature set, the product owner and the team can have a rational conversation. The product owner no longer says, “I need everything or it has no value.”

Too often, product owners (or other manager-type people) say, “You have to do everything by next Friday or it has no value.” I’ve seen very few situations where the maximum-value date was that close in and the team had to have finished all of the work. But even if that’s true for you, here are the benefits of ranking by value over time:

• The product owner might not even start work on this feature or feature set if the team can’t finish it when the feature runs out of value.

• The team can deliver the most valuable work and not have to start work that’s no longer valuable.

• The product owner might be able to have a conversation about which story is first, second, and third. That helps the product owner and the team break apart feature sets into smaller features.

Joe asks:

What If We Still Need “Everything” Now?

One of the ways agile approaches challenge people is in the idea of keeping things small. That “how little” thinking challenges many of us, especially if we can envision the entire product in all its beauty.

You might need to draw something like the “Expected Value Over Time” graph ​here​ for every feature in a feature set. You might discover some features lose value over time. Some features might gain value over time. Some might lose value soon and gain value later.

When people think there is value in “everything” now, they aren’t thinking about the value at all. They might be thinking about the pressure other people have put on them to deliver the “final, complete, finished” product.

Very few feature sets need to all be done right now. See if you can have a reasonable discussion with the people who rank the work.

While I like the idea of ranking by seeing the value increase (or decrease) over time, that’s not the only way to rank. Sometimes interim learning is most valuable for everyone.