Many product owners and Scrum practitioners in general really struggle with the concept of business value. While it’s easy to understand in the abstract, once you have to make it real in your team it actually becomes very difficult to describe a certain dollar or euro value to whatever story you want to work on. Today, I just want to go through some inspirations of what business value can be constituted of. We’re not going to go into the details of how to assign monetary value to it, but just some ideas of what could actually generate business value.

There are a couple of pretty easy cases. If you can sell more units, like more subscriptions to your SaaS service or more physical units, then that creates business value. Also, if you’re able to increase the price because of whatever user story you’re about to finish, that’s business value. Also, if you’re able to reduce the cost of goods sold — if you’re selling something and can get it for cheaper because you just implemented the user story — that’s very valuable. Or if you can reduce server costs and so on, this is absolutely business value. All of those three are very market oriented.

Then we have a second group of more risk-oriented things that can create business value. One of them is to make sure we’re more compliant. We don’t want to run the risk of being non-compliant and getting penalties from regulators. Anything that increases our compliance is actually business value, even though it’s a little bit more abstract. If you don’t do that stuff, you get a slap on the wrist and maybe a hefty fine, and then you’ll see that it would have been actually valuable to work on those items.

The next one is that you can reduce risk. If you have something you think is a little bit too risky, you can do something about it and get that risk level down. The third one is looking at hypotheses and checking them. Most people have heard of the MVP — the Minimum Viable Product — and it’s not about building something bad in a short amount of time. It’s about defining a couple of hypotheses: what do you want to know, building the product just to such a degree that you can test those hypotheses and then find out if those are true or not. If you build this thing to test your hypotheses, that’s very valuable because you don’t have to build the whole product. You just build enough of that product to test the hypothesis and then you can either continue or pivot.

Lastly, there’s this idea of capacity building. If we’re doing an item or a story in the sprint that helps us get better, it might be some training or some new capabilities that we have. It might be integrating Copilot into our software development process. It’s going to make us quicker. It might help us work with programming languages that we’re not very familiar with but still have to touch occasionally. This might be a good idea of creating business value on the capability side.

And lastly, there’s also the issue that a lot of teams have to perform repetitive, not very valuable tasks. People have to go through emails, do some almost manual labor tasks that are not very high impact but still need to get done. Maybe there’s a way to get rid of that, to automate it, to eliminate it completely. Anything you do in that regard that frees up the team is also business value.

If this was of interest to you, I run regular seminars on all things Scrum. You can head to teamflow.de to find more about it.