Customer Value: Short-Term and Long-Term

Consider both short-term and long-term value when selecting stories to implement.

Finding Value

XP books often say to choose stories by value to the customer, but don't always say much about how to find that value. ("Customer" in XP represents the role that selects and prioritizes stories; others call this the product manager or product owner.)

One breakdown I find useful is to think about short-term and long-term value. For each combination, there may be several types of value; some are described below.

Low Current Value, Negative Total Value

This quadrant represents the worst case.

Malicious Compliance

The team and the customer both know the feature isn't wanted (or may actually hurt the system), but they develop it anyway to hurt the money folks. Or, the development team knows the feature isn't valuable, but doesn't warn or attempt to convince the customer of that. (People are allowed to be wrong, but we want them to give their best judgment.)

High Current Value, Negative Total Value

This quadrant represents things that benefit the short-term only. In both these cases, sometimes the development team will "know" the feature has low total value. They certainly should make their case to the customer. But one of the reasons there's a customer involved is because the customer can recognize value in some things developers would not.

Ego

Some features are chosen because the customer wants to make a mark, not because they're truly expected to be valuable when considered in the long run. Often times, the customer may get warning about this. (Unfortunately, extraordinary features may also draw the same warnings.) This is a place where the vision comes into play – is this feature consistent with that vision?

Wrong Guess

Some features are expected to be worth more, but the guess turns out wrong. That's going to happen sometimes. But it's still worth looking for warning signs that a feature isn't going to be as useful as expected.

Low Current Value, Positive Total Value

This quadrant represents features that are an investment.

Demonstrate Capability

Sometimes a team is put to a test: develop this feature, so we can see whether to trust you with more, and to assess the team's capability and/or commitment. A pilot project has this flavor; a pilot is often not trivial (because then it wouldn't prove anything) and not huge (because then there's too much risk).

Teambuilding / Quick Win

This applies particularly for a new team or one that's not been successful in a while. A feature may not be particularly valuable, but it can provide something the team can gel around. Often, this feature can be something that is visible and that everybody can understand. For a particular team, it may be a good choice, even though a gelled team might start with a different story.

Information / Feasibility

A feature may be developed for the information it provides, to enable a better course of action later. Sometimes, that information may establish that something is not viable or not important. That can be very valuable information; it helps us adjust to reality and move on to something more valuable.

There are a couple interesting twists: sometimes the information that some aspect of a project is non-viable is significant enough to cause a project to be canceled or to change its goals significantly. By getting this important information early, a project can save huge amounts of money. (After all, if it's non-viable, you'll certainly find this out by the end, regardless of how much you've spent to get there.) Think like a venture capitalist – you may have a portfolio of things; some will fail, some will be strong performers, a few will be huge hits.

Sometimes, you do a feature to convince someone else that it's not feasible or not as useful as expected. The XP-style "spike" does an experiment to find out whether something will work. It's often much better to do a quick experiment than waste hours or days arguing about it.

Option Value

A feature may not be valuable itself, but investing now gives us the ability to deliver other valuable features later (especially if that's cheaper, faster, etc.) This sometimes provides a push for breadth in a project – rather than focus on one specific area, paint the whole product lightly first. Totally different areas may reveal different challenges, and will help you move in any direction later.

Some infrastructure stories fit this category. A feature may be needed to enable other features to build on it. In XP, the team tries to minimize features like this, preferring to build infrastructure a little at a time. (One reason is that the customer is not always in a position to judge the value of pure infrastructure.)

High Current Value, Positive Total Value

This quadrant represents the obvious winners: features that you know you should do.

Direct Value

Features with direct value are the bread-and-butter features: those that will result in making or saving money in their use, those that are obviously useful, those that provide a straightforward new capability.

Synergy

Some features are even more valuable in combination with other features. For example, print preview is of some use by itself, but even more use when combined with the ability to print.

Domination

Domination is a special type of synergy: it helps a product establish itself as dominating an area. For example, "we have the most comprehensive style sheets on the market," "we have the best performance," etc. It can play to the bandwagon effect, making a product desirable because other people want it.

Lock-In

Some features are valued because they lock the end-user in to a product. For example, a proprietary file format may prevent others from reading your information. Note that this can back-fire too – this is something a company values more than end users do. Lock-in may slow down movement of customers who want to leave, but it also keeps people away in the first place.

Summary

Features with direct value are the easiest to choose, but not always the best. Be aware of opportunities that may seem low in value now, but can be extra valuable later. And guard against features that will never become valuable.

[Written October, 2004. Thanks to Christian Pekeler for catching a couple minor errors.]