The Scrum framework exists to deliver value to stakeholders sooner. Sounds good, right? But when is something “valuable”? For something that seems so central to Scrum, there is little guidance on what “value” means. And we fear that it remains only a word if there is no meaningful definition for it.
In this post, we offer a more fine-grained approach to understand what “value” means to your product and the items on your Product Backlog, and to start a conversation around that with your team and its stakeholders.
This post is a rewrite of one of our most popular posts. This rewrite includes many new insights and perspectives, and we changed our minds here and there. You can also download a full-size poster (PDF) here, or even get a fully prepared do-it-yourself workshop (PDF) to use the model with your team and stakeholders.
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. Each Increment brings the team and its stakeholders one step closer to a valuable Product Goal. 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 developers. While that sounds like a great idea, what does that actually mean in the real world?
- How can you state with certainty that 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 the Product Goal inform what is valuable?
- 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 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 how can a Scrum Team be effective when they lack a working definition of value? We 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 valuable. In fact, this is what we often see in cases of 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. Lets look at two perspectives to understand value:
Value & Stakeholders
Whenever the Scrum framework talks about “value”, it refers to transactions between the Scrum Team and its stakeholders. In other words, something can only be valuable when it is delivered to and validated by stakeholders — until then any value is purely hypothetical.
As we wrote about in another post, stakeholders are the people with an actual stake in the product — not the people who merely relay or proxy needs they don’t personally have. They stand to 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. While your colleague may have a useful opinion about your product, or how to market it, he or she probably doesn’t use it nor invest in its development.
This gives us one important insight; we need to look at value from the perspective of the transactions that happen between actual stakeholders (not proxies) and Scrum Teams. This also highlights one of the challenges that Scrum Teams in large organizations often face. Their actual stakeholders are often hidden behind layers of organizational fat, the question of what is valuable is often ignored altogether, and thus the focus shifts to getting as much work done as possible (without regarding how valuable that work is).
“ This also highlights one of the challenges that Scrum Teams [ …] often face. Their actual stakeholders are often hidden behind layers of organizational fat, the question of what is valuable is often ignored altogether, and thus the focus shifts to getting as much work done as possible”
Value & Longevity
This perspective on the transactions between stakeholders and Scrum Teams also draws attention to the sustainability of future transactions. After all, if a Scrum Team gives all their work away for free they, or their product, won’t be around for long. Similarly, the budget probably doesn’t allow a team to answer any potential need from stakeholders. This is obviously more of a concern for stakeholders that invest in the development of the product (e.g. investors or the organization that pays the salaries of the Scrum Team) than for those primarily using it. But ultimately, both groups benefit from sustainable development.
This aspect of longevity and sustainability is why “Business Value” may be more accurate than just “Value”, even though the Scrum Guide talks exclusively about the latter. A common definition of Business Value is: “all forms of value that determine the health and well-being of the firm in the long run”.
This perspective on longevity also explains why the 2020 Scrum Guide formalizes a singular Product Goal to bring focus to the development over a large number of Sprints. Its entirely likely that there will be many more needs from stakeholders than can or should be addressed, and the Product Goal offers teams a touchstone to base their decisions on what is valuable and what isn’t (at least not now) on. A particular stakeholder need may be incredibly useful, but if it doesn’t align with the Product Goal, it simply isn’t valuable enough to spend time on that could’ve spent on more valuable items instead.
“This perspective on longevity also explains why the 2020 Scrum Guide formalizes a singular Product Goal to bring focus to the development over a large number of Sprints.”
Now all these considerations are still abstract. 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 item on it. How you can determine if something on the Product Backlog is “the right stuff” or “the wrong stuff”?
Five Types Of Value
With this in mind (stakeholders & longevity) in mind, we went ahead and analyzed the Product Backlogs for (commercial) products we have developed with Scrum Teams. We categorized the items into separate types of value and ended up with five that seem to describe most cases quite well. We’ll discuss these in no particular order below.
Note: because our personal experience lies mostly with commercial organizations, most of our examples are from there as well. Not all types may be equally relevant to non-commercial organizations, especially “commercial value”. But even for a non-commercial organization, it can still make sense to look at items from an economic perspective.
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.
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.
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.