How to measure value

The economic struggle makes Scrum at Scale into a money-factor. While doing projects you have to consider what features actually have business value. But value isn’t only a questions of making money. There are other factors that are linked indirectly to money. Or that are even not at all connected to it.

About a week ago I had the chance to listen to Jeff Sutherland speaking about Scrum at Scale at the Agile GOTO Night in Zurich. There were two things that astonished me most (although they are pretty obvious). First of all Scrum can be used in so many contexts. Since I experiment with Scrum as a didactic method, I believe that it works in other contexts, too. Still, I think it is amazing: Scrum in manufacturing and in shipping. I do feel inspired to experiment even further.

The second thing was about money. I myself don’t feel as a money-person. I learnt to consider the money-factor, sure. But intuitively there is lot more to things than economic value. And since my field of expertise is communication and social competency, I tend to focus more on the process and soft factors like motivation and engagement than on what financial advantages might come from agile. (It’s all interconnected though!)

Considering the examples of Jeff’s Scrum consulting expertise it suddenly hit me: Scrum is a huge economic factor. He got into that topic and explored it more profoundly by analyzing the value of projects. According to his chart only 25% of all the projects are actually valuable. About 45% of the projects (or features) are wished for by customers but actually never used in practice. And 30% shouldn’t be done at all.

At break time I found myself in a discussion about what value could be. We agreed that it isn’t simply business value. Sometimes you value projects that do not make money immediately or you cannot be sure they will make money at any point, like for example hack days. And sometimes you value even projects or activities that are not connected to money directly at all. For example you decide to take a break together or to discuss something with no (immediate) relevance to your work or to tidy the office space. Of course, afterwards you might be more efficient because you find your stuff again or you are more motivated and therefore more engaged and focused. Still: Do you put these kind of things in your backlog?

Actually, I do. It helps me, not to forget doing and valuing things for my mental hygiene. The last weeks and months I worked really hard on my book about agile communication. Since I have a day job, too, there wasn’t much time for things like housekeeping and all. Of course, cleaning and vacuuming is in my backlog. But I try to make sure that having a cup of tea and staring in the air to leave my thoughts some space once in a while is valued at least as much as the things I do have to do anyway.

Identifying the true 30% of projects that are the waste seems to be far more difficult. Cutting them could have an impact on our efficiency – I do agree. But: Are we sure that impact will be to our advantage, so to say: to increase efficiency? I will have a look into that, as soon as there is some free space in my backlog.