What Is This Thing Called “Value”?
How to have a conversation about what value means to you and your stakeholders
Pick up any book about Scrum or Agile software development, read a blog about it or talk to someone about it, and you’ll likely be overwhelmed by an avalanche of vague, abstract concepts like “technical debt”, “Agile”, “commitment”, “Done” and “shippable increment”.
My favorite is “Value”. Everyone agrees that the Scrum Framework is about generating value for stakeholders. But few people define “value” into something that’s actually meaningful in the context of their work on a product.
Now, this is a systemic problem with management theories. They are often populated with terms that seem profound on the surface, but are hard to translate into actual behavior and decisions in the real world. Take terms such as “waste”, “flow”, “empiricism”, “quality”, “leadership”. Without further operationalization, they probably mean different things to different people. When we use container words like this, and don’t investigate what they mean to us, we can easily end up playing “language games” where we only talk the talk, but don’t walk the walk.
In this post I explain why this is tricky. I will also attempt to operationalize value into more meaningful categories and provide a cheatsheet for use when preparing your Product Backlog (see below).
Value in Scrum
In the Scrum Framework, it is important that Scrum Teams frequently delivers a valuable Increment. Without this, it is difficult to learn about what else is needed and to reduce the risk of complex work. In the Scrum Team, the Product Owner is responsible for maximizing the value of the work done by the Development Team. You’ll probably nod in agreement here. But what does it mean in the real world? What does it mean in your own work environment? Your company or organization? Can you answer these questions:
- How can you state with certainty that something valuable was delivered by your Development Team?
- Is all delivered (working) functionality directly valuable to the organization?
- What does “maximizing value” mean in terms of behavior and decisions?
- How do you know which items on the Product Backlog are more valuable than others?
- Are there different kinds of value? Are they equal? How do you compare them?
- Whose perspective do we take when deciding what has ‘value’?
These questions are difficult to answer. The Scrum Guide cleverly stays out of defining “value” and argues that it depends on the context and the stakeholders for which the work is done.
But what happens if there is no good working definition of value? I can easily imagine a Scrum Team that works through their Sprints perfectly, delivers high-quality Increments in a steady pace for their Product Owner, but does not actually deliver anything of value to the organization. So, just “doing Scrum” is not going to magically result in more value. It’s still very easy to work on the ‘wrong stuff at the wrong time’.
Different kinds of value
I prefer to talk about “Value”, even though the Scrum Guide calls it just ‘Value’. This emphasizes that the work that a team does should benefit the organization or business as a whole somehow. But note how vague that is. Thankfully, when it comes to ‘Business Value’, there are many usable definitions available in the literature and on the internet. This is one from Wikipedia:
Business value is an informal term that includes all forms of value that determine the health and well-being of the firm in the long run.
Although this definition makes the sensible point that something has business value when it positively impacts the longevity of an organization, it is still quite vague and broad. It will not help us when we get into the nitty-gritty details of setting up a product backlog and determining the business value of every epic, story or item on the backlog. Simply put; we need to have some way to determine if something on the backlog is ‘the right stuff’ or ‘the wrong stuff’, and when prioritizing we should be able to say if this is ‘the right time’ or ‘the wrong time’.
Scrum is geared towards software development, although it can easily be applied to other kinds of work. I think we can distinguish several kinds of value that can be generated for the business / organization by by the work that a team does in a sprint. I will list them below (but feel free to suggest more in the comments).
Commercial value is the most obvious one, and consists of functionality or work that translates into profit directly, like:
- A new version of a software package that customers will pay for to acquire;
- A new piece of functionality that can be paid for, like modules in on-demand web-apps;
- Changes that reduce operating costs, like reduction in required servers by improving code or cheaper distribution to customers (e.g. via Steam instead of packaged);
- Being able to send a bill to a customer for the work that was done;
- Improve the subjective value of the application so people are willing to pay more for it (in Lean Six Sigma this is considered quality or customer value, something Apple is quite good at);
The key question to ask is ‘How much revenue or profit does this work result in?’.
Market value increases the potential number of customers, like:
- Functionality that draws in a new group of customers;
- Porting applications to other platforms, like smartphones, from iOS to Android, etc;
- Adding features that the competitors doesn’t have (or implement them better);
The key question to ask is ‘How many new customers will we be able to serve?’.
Efficiency value increases organizational efficiency and thereby decreases operating costs, like:
- Reduce the amount of errors in a task or increase speed (by automating it or parts of it)
- Increasing the usability or quality of an application to reduce load on support desks;
- Reducing the amount of time needed to set up new customer environments or deploy them;
- Decreasing the time to market;
The key question to ask is ‘How much time or money will this save us?’.
Customer value increases the likelihood that customers will continue to use your product (‘make it stick better’), like:
- Improving usability in an application to make it easier to use (and reduce frustration);
- Adding a new feature that is commonly requested by users;
The key question to ask here is ‘to what extent will this decrease the likelihood that a customer leaves?’.
Future value increases the chances of more easily achieving one of the above values in the (near) future by investing in innovation and learning now, like:
- Investing in a new (custom or open source) framework that can be used for future development;
- Reducing technical debt in code to make future changes in the code easier or less error-prone;
The key question to ask here is ‘How much will this save us in time or money in the future?’.
Although not all types of value will be equally relevant to every type of organization, I think most of them can be translated for different kinds of organizations, commercial or otherwise. There are many other kinds of value that can be identified, but I think they can all be narrowed down to this set. But feel free to prove me wrong :)
A Product Owner should be able to make the case for every item on the backlog and should be able to translate into (business) value for the organization. As specifically as possible (but some pragmatism is advisable here). Simply put; all the work that a team does should translate in one of the business values listed above so as to prove that it is ‘the right stuff at the right time’. If it doesn’t, or if the case isn’t strong enough, the Product Owner should not make the team spend time on it.
Measuring business value?
Ken Schwaber recently wrote about measuring the outcome of software development based on the value it generates for the organization as a whole (and not just the project or individuals), and making decisions based on these measurements. This takes away the intensely subjective nature of many decisions, but requires that we somehow operationalize business value.
I agree with the sentiment of that post, although I am a little skeptical on how well we can actually operationalize business value to such an extent that it can be measured objectively and reliably. But even so, I’m sure it’s possible to more accurately measure the value that is generated by software development and make more informed (less subjective, less politicized) decisions based on that information. And I strongly believe that that’s a good thing, because it avoids wasting precious time, effort and money on work that does not move the organization and it’s employees forward.