Five Types Of Value
By: Christiaan Verwijs
Tags: Scrum, Value, Agile

Commercial Value

Commercial value is the most direct type of value and consists of all the items on the Product Backlog that directly generate revenue for the organization that develops the product. When all other things are kept equal, the work would result in a net profit.

For example, an item generates commercial value when — upon its delivery — customers pay to acquire it. This could be a new version of your product, a new feature, or an unlockable add-on. It could also be a new bit of paid downloadable content, a new product in your webshop, or something else that customers pay for directly. Although there may be some layers between the delivery and the payment, we like to think about these items as the lines that appear on an invoice that is sent to a customer.

The key question to ask here is: “(With the Product Goal in mind) how does this item increase our revenue or profit?”. The easier it is to answer this question, the more clearly it delivers commercial value. If it turns out to be very hard to put a finger on it, you may be dealing with another kind of value (see below), or the item may not actually be valuable at all and you need to remove it.

“The key questions to ask here is: ‘(With the Product Goal in mind) How does this item increase our revenue or profit?’”

Efficiency Value

Not all items on Product Backlog will generate revenue. But items can also influence profit directly by decreasing the costs of production, maintenance, and delivery. These are the items that represent work that simplifies, automates, reduces, or smoothens other work that happens for the product; it makes other work more efficient. In economic terms, these are the items that improve your cost efficiency by spending less money for the same amount of value that is delivered to stakeholders. Or, if you’re not a commercial venture, how much time it saves you. This is efficiency value.

For example, if a change to the codebase allows you to run the same product with fewer servers, you are generating efficiency value. But it can also involve the automation or simplification of tedious and repetitive tasks that are necessary for the development, operation, or delivery of your product. For one of the products that we helped develop, we had items on our Product Backlog to reduce the time needed to set up the product at a customer site. Although that item in itself did not generate money, it did save us (and the customer) money.

More indirectly, items can also reduce work elsewhere and thereby reduce costs. For example, when an item increases stability in the application and thereby offloads the helpdesk from a significant number of calls every week.

For each item, the key question to ask is “(With the Product Goal in mind) how does this item save us money or time?”. If this is not clearly the case, you may be dealing with one of the other types of value. Or the item isn’t valuable at all, and you need to remove it.

“For each item, the key question to ask is ‘(With the Product Goal in mind) how does this item save us money or time?’”

Market Value

A product is only as successful as the number of potential users and customers that is aware of it. More often than not, product development involves a lot of work to increase this awareness, to move into new markets, or to distinguish from competing products. This work represents market value.

Marketing activities are a good example of this kind of work. For example, this could be the set-up and copywriting for a simple website that promotes your product. Or starting a marketing campaign on LinkedIn. Even writing a blog post, recording a podcast or video would be “market value” from this perspective — as long as it is primarily concerned with creating awareness for your product.

From a software development perspective, this could be the porting of an application to other platforms (e.g. from iOS to Android or from Steam to Xbox Live). Or adding features to appeal to a new group of customers.

For each item, the key question to ask is “(With the Product Goal in mind) how does this item allow us to attract more users or customers?”. If it turns out to be hard to make the case for how this item attracts new users, you may be dealing with another kind of value.

“For each item, the key question to ask is ‘(With the Product Goal in mind) how does this item allow us to attract more users or customers?’”.

Customer Value

Even when your product is generating revenue, has high cost-efficiency, and is well known to users, it is still hard to be successful when customers don’t stick around or switch to a competitor the first opportunity they get. So there is value in work that makes your product more useful and valuable to its customers. This effectively increases the “stickiness” of your product, as Eric Ries calls it in The Lean Startup. This is customer value.

User experience optimization is a good example of work in this category. This happens when you make your product easier to use and understand, less prone to errors, and more suited to the task that a user sets out to perform with it. But it also includes the implementation of features that customers don’t directly pay for (commercial value), but are there because it is commonly requested and keeps them invested in your product.

For each item, the key question to ask here is “(With the Product Goal in mind) how does this item increase the likelihood that a customer continues to use our product?”. If you can’t clearly answer this question, you may be dealing with another kind of value.

“For each item, the key question to ask here is ‘(With the Product Goal in mind) how does this item increase the likelihood that a customer continues to use our product?’”

Future value

Finally, there is inevitably going to be some work for your product that doesn’t deliver any clear kind of value upon completion but might cause huge problems or significant costs in the (near) future when it isn’t done. This is future value.

Research and innovation are examples of work in this category. Sometimes you need to research alternative technical solutions to a problem that you face with your current stack. Or you want to improve the practices and processes of your team, and this requires that you spend some time learning.

The reduction of technical debt also seems like an example in this category to us. Technical debt consists of all the shortcuts and quick fixes that were applied to the product before — probably in a pinch —that may have worked well then, but are causing problems now. For example, automated tests may be missing in some important parts of the code. Or documentation wasn’t updated. Or chunks of code have spaghettified to the point that developers don’t dare to touch it, afraid that it might all collapse like a Jenga tower of code.

One of the risks of future value is that all time is spent on something that could be valuable in the future, without considering what is valuable right now

While it might be tempting to remove this kind of work from the Product Backlog, these items could represent hedges against future disasters. Even though the future remains largely unknown, some of these hedges may be wise to keep — even when they don’t immediately deliver value.

For each item, the key question to ask here is “(With the Product Goal in mind) how does this item save us money or time in the future?”. If you can’t clearly answer this question for an item, you may be dealing with another kind of value. A good Product Backlog should have only a few of these items, and not too many.

“For each item, the key question to ask here is ‘(With the Product Goal in mind) how does this item save us money or time in the future?’”

What about compliance?

When we first shared this taxonomy, one of the most common questions was how to deal with compliance with existing regulations, protocols, and certifications. Shouldn’t “Compliance Value” be its own type, as some suggested?

We struggled with that question then, and we still do now. Our concern here is that compliance is not really valuable in and of itself. Rather, it is a means to an end that — hopefully — is valuable. For example, when a customer demands compliance to a protocol and they pay for it, it is clearly commercial value. If a customer doesn’t pay for it, but they still get it to keep them on board, it is customer value or market value. If the compliance involves security or hardening, it is done to prevent damage caused by potential security breaches. And that makes it examples of future value.

We’ve seen too many examples where compliance is followed for the sake of compliance, which in turn caused significant costs, decreased efficiency, and made it harder to release. While that was justified in some cases where this happened, it certainly wasn’t in others. So to avoid this, we encourage you to dig deeper than just the compliance and determine why that compliance is valuable.

Furthermore, we feel that compliancy is better suited for a Definition of Done. Unless you’re talking about specific features or functionality, most compliancy generally consists of quality guidelines. And isn’t that what a Definition of Done is for, precisely?

Start A Conversation About Value

The taxonomy we propose here is certainly not complete. The various types overlap in several ways, and some items may not fall clearly into any type — and still be valuable.

Start a conversation about what types of value appear on your Product Backlog. For example, the Liberating Structure User Experience Fishbowl can work for that

But that is beside the point. The point is that you should have a conversation with your team and your stakeholders about what makes each item on your Product Backlog valuable. For items where you can easily categorize them into one or more of these types, you’re probably dealing with something valuable. If you can’t, your team, and especially your Product Owner, needs to have an exceptionally compelling reason for why it is still on the Product Backlog. After all, how does a Product Owner maximize the value of the work done by the Scrum Team by keeping items around that are seemingly non-valuable?

“After all, how does a Product Owner maximize the value of the work done by the Scrum Team by keeping items around that are seemingly non-valuable?”

We hope that this post inspired you to start a conversation around value with your stakeholders and to make purposeful decisions about what to keep on your Product Backlog and what to discard.

You can also download a full-size poster (PDF) here. Or get a fully prepared do-it-yourself workshop (PDF) to use the model with your team and its stakeholders.