I’ve seen some coaches and Scrum Master advocating for optimization of the value delivered by the team by applying a ratio of the value, divided by the effort.
I was never very comfortable with this approach. Here’s why and how I prefer a backlog to be optimized.
📈 Ratio value/effort
If you don’t know the ration value/effort, here’s an example of what some teams are doing.
The Product Owner defines a number representing the expected value from the Product backlog items, to simplify, let’s say they are user stories.
- User Story A has 100 value points
- User Story B has 80 value points
- User Story C has 140 value points
These points are usually abstract values, but some teams use dollars or euros instead. It doesn’t matter for the purpose of this article.
The developers (usually) estimate each element in refinement, with effort -or complexity- points which are usually called story points. You may have heard of poker planning, the estimate may be the result of a poker planning. So we will have:
- User Story A has 20 story points
- User Story B has 5 story points
- User Story C has 13 story points
Now, you will make a ratio, so that:
- User Story A has has a ratio of (100 ÷ 20): 5
- User Story B has has a ratio of (80 ÷ 5): 16
- User Story C has has a ratio of (140 ÷ 13): 10,7
Using this ratio, as a Product Owner, you should logically order the backlog like this:
- User Story B (better ratio)
- User Story C
- User Story A (worse ratio)
Do you see the problems?
❌ THE PROBLEMS
Problem one
The first problem I can see, and what bugged me the most, is that you expect the most value from User Story C, but you choose to work on something else.
I really don’t like that!
Problem two
But that’s not all, if you look carefully, what do you use to make this decision? You use expected value and estimated effort. “Expected” and “estimated”. You use two arbitrary and imprecise values you set, and mix them to give an absolute order and to make decisions.
Using one imprecise value is not the best but that’s all you have, you shouldn’t use two. It exponentially increases the risks of being wrong and the consequences. And you will be wrong.
I really don’t like that too!
Before I tell you which better approach I see, there is one more big problem with the ratio.
Problem three
The expected value will be wrong, most of the time. And that’s normal. If someone tells you otherwise, ask him, or her, to prove it with data, not intuition or… wish.
So if you will be wrong most of the time, you want a process to know you’re wrong very quickly. And you want to know it for what you expect to be the most valuable things.
Because of that, you should order your backlog by what has the most value now, so you can deliver this value sooner and correct your decision sooner too. The first thing you should do if not already done is to get rid of the less valuable imprecise value: effort estimation.
🔭 ANOTHER APPROACH
Well… it’s not really getting rid of it. Let’s dive into that.
There is something I didn’t tell you yet, and, it should have been in your mind from the beginning: “Hey Const, you tell us what is the ratio value/effort, but you didn’t mention why some teams are using it!”
Always start with why. But in this case, most of the teams I met didn’t know why they were using it -or, it was just because “the coach told us so, to be agile”- and frankly, it usually makes sense for them, in their guts. “Yeah, it seems to be a good idea to optimize doing what has the best ratio, the best ROI (Return On Investment).”
Indeed, teams working like that usually do it to get the most value from their time. Whatever value it is. Whatever it’s good value, the most important thing is that the team is busy, that they produce a lot. Even if what they produce is not really important now.
This is the problem François Dupuy describes in his second volume of Lost In Management about the “common sense”. Sometimes -often?- it blocks the reasoning. “It’s so obvious, don’t waste our time trying to confront it”.
So what if I tell you that you can work on the most valuable item, right now? And that you don’t have a lot of things to change?
Let’s go.
You want -and you should- work on the most valuable item, but, the team says that’s it’s way too big. They’re certainly right.
So instead of asking what less valuable item they can do instead to be kept busy, next time try to ask them to narrow the most valuable item (a User Story or whatever you use) so they can start delivering a part of its value.
It’s always possible. You can narrow it in many ways: by addressing only a small portion of a user group (or even one user!), or by addressing only a small portion of the domain, per example, only the case where the user pays by credit card.
By doing that:
✅ You start delivering value for some users -not many, but not zero
✅ You learn from them, you can adapt your solution, and reduce the risk of making something useless.
✅ And you work on what is the most valuable
✅ You get the most value from your time