In Scrum, it is important that a Scrum Team very frequently delivers value. The Product Owner – who is part of the Scrum Team – is responsible for maximizing the (business) value that a Development Team delivers during the sprints. You’ll probably nod in agreement here, as it sounds very profound. 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 do you know if work done by the development team results in value?
- 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 functionality has more business value over other functionality?
- 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 the definition of ‘value’ altogether and argues that it depends on the context and the organization where the work is done. In fact, the Scrum Guide does not even provide a definition of ‘value’ at all, but strongly insists that a team should deliver value and that the Product Owner is the key person to decide what has value and what does not.
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 functionality 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 business value
I personally prefer to talk about ‘Business 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
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
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
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
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
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?’.
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.