Pick up any book about Scrum or Agile software development, read a blog about it (like this one) or talk to someone about it, and you’ll soon be overwhelmed by an avalanche of vague, abstract concepts like ‘technical debt’, ‘velocity’, ‘commitment’ and ‘shippable increment’. My personal favorite is ‘Value’ or ‘Business Value’. Everybody always agrees that Scrum is all about generating value for organizations. But few people are able to define ‘value’ into something that’s actually meaningful in the context of a project or organization.
Now, this is a systematic problem with all management theories. They are often populated with terms that appear to be very profound on the surface, but a very hard to translate into actual behavior and decisions in the real world. Take terms such as ‘waste’ (in Lean), ‘flow’ (in Kanban), ‘empiricism’, ‘quality’, ‘leadership’, ‘. All this use of abstract terminology can lead us into playing ‘language games’ where we talk the talk, but don’t walk the walk. This makes all these concepts potentially nothing more than ‘buzzwords’.
I think this is dangerous, and I will explain why. I will also try to operationalize value into more meaningful categories and provide a cheatsheet for use when preparing your backlog (see below).
Value in Scrum
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 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.
If you want to know more about (value-driven) Evidence Based Management, please join us at the Scrum Day Europe 2014. I am one of the co-organizers, and we’re still looking for people that are willing to take the soapbox and talk about their experiences and views on EBM and value. You can send in your proposal until March 7th. For more information, check out www.scrumdayeurope.com.