We talk about value a lot in agile. The whole point of agile is often given as "the ability to deliver value quickly". Lean looks at value streams and flows of value. But when we say value, what do we really mean? What is value? The dictionary tells us that value is "the regard that something is held to deserve; the importance, worth, or usefulness of something."

So value describes something that is important to someone. But who? When we ask ourselves this question, we usually come up with and answer of - "the customer". This isn't a wrong answer, customer value has to be our of our key drivers. Make the customer happy by giving them what they want. That's the key to business success. But note that I said "one of our key drivers", not "our key driver". There are other "someones" out there who are also important, and often get forgotten. What about the organisation itself? Its employees?

How many times have you seen a team's backlog that is entirely dominated by new customer features while other important things, like maintenance, upgrades, and refactoring languish at the bottom because they have "no customer value"? We often focus on direct customer value to the exclusion of all else because that's the obvious source of value. There are other important ones that get ignored though.

I tend to divide value into three types. The is direct customer value, the obvious one. Things that are directly useful to the customer and will directly generate revenue for the organisation. So far so obvious, but what about the other two? The other two are learning and enablement.

Learning has value to the organisation and to the customer. If you think about it, a technical spike has learning value - we are learning whether something will work or not in order to prevent an expensive investment in something that is doomed. That learning reduces risk which is a direct benefit to the organisation.

What about developing a couple of options and testing them to see which is best? No direct customer value but running an experiment like this lets the organisation evolve a better solution which has direct value to the organisation and indirect value to the customer.

Training has learning value as it allows the organisation to develop better/faster/with newer technology/with improved quality.

So learning is an important source of value that is often overlooked and ignored in favour of the more obvious direct customer value. What about enablement?

Enablement value is the hardest to see. Something that has no enablement value may have no direct value on its own, its purpose is to enable future value.

Take that database upgrade that has been languishing at the bottom of your backlog for ages. It may not have any direct customer value - the customer doesn't care which version we run, but it might allow you to deliver a bunch of new features that are not possible (or just really hard and expensive) on the current version. That's enablement value. It unlocks future value.

Refactoring is something that usually either languishes at the bottom of the backlog for "when we have time" (ie: never) or gets stuck in by the team, usually at the cost of working extra hard (which is not sustainable), or tacked on to other stories which makes them bloated and less likely to get done.

Looked at through an enablement lens, refactoring is a different proposition. Refactoring that code may allow new features to be added that weren't previously possible. It may allow other features to be delivered faster, earlier and more cheaply. That's enablement value.

What about setting up an environment to allow AB testing? That potentially unlocks a lot of future earning value.

Some teams try to reword their enablement and learning items into customer value terms which always looks a bit awkward and is seldom successful - "as a customer I need the database upgraded to version 7 so that performance might improve and I get a better user experience". "as a customer I need the validation code refactored so that I can validate forms faster". Not real convincing, and this type of story tends to stay at the bottom of the backlog as well.

Most of the time we look at our backlog only through the lens of direct customer value, because it's easy to identify. I like my teams to make three passes through their backlog when doing prioritisation, each with a different lens. The first pass is the customer value pass - "what items in the backlog have the highest customer value?" That's pretty much what we do now. The second pass looks at the backlog through a learning lens - "which items on the backlog give us the greatest learning opportunities?" The third pass looks at the backlog through the enablement lens - "which items on the backlog enable the greatest future value?" Once we have the top ranking items through all three lenses we can assess them against each other and come up with our priorities. Using T shirt issues to represent the size of the value for each story works well and gives us a way to somewhat objective rank a customer value story against an enablement or learning story.

This doesn't guarantee that that refactoring story will get done, it may well be that there are a bunch of really high customer value stories in the backlog that trump the more modest enablement value of the refactoring, but it does guarantee that it will at least be considered.

Tagging each of your stories with a value type also lets you do some more strategic, portfolio level assessments of the work you are doing - Are we delivering enough customer value? Are we setting ourselves up for the future by doing enough enablement? Are we doing enough learning to minimise risk?

So, don't throw away your customer value lens, add another two to your toolkit and look at your backlog through fresh eyes.