What Is This Thing Called “Value”?
How to have a conversation about what value means to you and your stakeholders
Since writing this article, we’ve changed our minds on some aspects of this post. And get a better understand of others. So a substantial rewrite of this post is available here.
You can pick up any book about Scrum or Agile, read a blog about it or talk to someone about it, and you’ll be overwhelmed by abstract terms like “technical debt”, “Agile”, “commitment”, “Done” and “shippable increment”.
Of those abstract terms, my favorite one is “Value”. While everyone seems to agree that the Scrum Framework exists to deliver value to your stakeholders sooner, there seems to be little guidance on when something is actually “valuable”. And for something that seems so central to Scrum, I fear that it remains nothing but a word if there is no meaningful definition for it. In fact, the recent update to the 2020 Scrum Guide adds “useful” as another criterion for what the Increment should be. But this makes me wonder; how can something be useful, but not valuable? Or valuable, but not useful?
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 definition, 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).
Maximizing Value in Scrum
In the Scrum Framework, it is important for Scrum Teams to deliver a valuable Increment as frequently as they can — at least once per Sprint. Without this, it is difficult to learn about what else is needed and to reduce the risk of complex work. The Product Owner is responsible for maximizing the value of the work done by the Development Team. While that sounds very true on the surface, what does that mean in the real world? What does it mean in your own work environment? Can you answer these questions?
- How can you state with certainty when value was delivered by your Scrum Team? What would you need to observe or see happening?
- Should all the work that your team delivers be immediately valuable to the stakeholders? Or can there be some delay?
- What does “maximizing value” mean in terms of behavior and decisions that a Scrum Team makes?
- How does a Scrum Team decide which items on the Product Backlog are more valuable than others? What do they base these decisions on?
- Whose perspective do you take when deciding what has “value”?
These questions are admittedly 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.
And while I see the merit in that decision, how can a Scrum Team be effective with Scrum when they lack a working definition of value? I can easily imagine a Scrum Team that works through their Sprints perfectly, delivers high-quality Increments to their stakeholders every Sprint, but does not actually deliver anything of value to the organization. In fact, this is what we often see in cases of severe Zombie Scrum; although everyone goes through the motions, there is nothing of value at the end. Just “doing Scrum” is not going to magically result in value.
Value & stakeholders
Whenever the Scrum Framework talks about “value”, it refers to transactions between the Scrum Team and its stakeholders. As we wrote about in another post, the stakeholders are the people with an actual stake in the product. They stand to personally gain when the work that the Scrum Team delivers is valuable, and they lose when the team doesn’t. So while the people that actively use your product or invest in its development with their money, are probably your stakeholders, your colleague from the marketing department probably isn’t.
I prefer to talk about “Business Value”, even though the Scrum Guide calls it “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).
1. Commercial value
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?’.
2. Market value
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?’.
3. Efficiency value
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?’.
4. Customer value
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?’.
5. Future value
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.
Download the poster. Or download a fully prepared string of Liberating Structures to explore what is valuable about your product with your stakeholders.
