This article is NOT exhaustive in the effort of finding alternatives to measuring value. There is no wrong choice, no inapplicable method, and all are welcome to suggesting new ideas.
Before all the right-winged liberals jump up from their seats, let me be clear: no measuring unit substitutes revenue. In an ideal situation, you would be able to measure everything you do in $$$. However, an ideal situation is sometimes scarce. And if that is the case, how do you measure value?
This is the most common scenario in my experience: you have clients or stakeholders. They demand that some feature is prioritized in your backlog. You try addressing their needs, find that what they had in mind is different from what will bring the results they want, groom your backlog once more, and you say “Ok! So we are all in accordance, and this is what we’ll do. Now I need to know how much value this aggregates to the product. Can you help me define metrics for that?”
That’s usually the point where they are blankly staring at your face. You say “you know… value? How much do we stand to gain from implementing this feature? Or how much we believe we will save…?”
Ok, so these guys presented this very pressing need to you — disregard the fact they first tried pushing a technical solution down your throat — insisting that is vital to the business, and absolutely urgent. Maybe they did take the time to flourish things a bit and say “it will sell more” or “it will save money”, but when you ask how much, their best answer is “a lot!” Not only they haven’t done any research to base that assumption, they also have no idea as to how you are going to measure value. And you’re thinking “my backlog was just fine before that”.
Now, if you are some kind of IT unicorn, you will be able to tell your client/stakeholder to come back when they have at least some data. However, if you are a real person, in the real IT market, you will have to find another way to measure value and prioritize your backlog.
There are 10 types of people…
The easiest way to determine value per backlog item is by simply asking your stakeholders to grade each PBI from 1 to 10. If one of them decides to rig the system by grading everything 10, you can always take an item you know is less relevant and say “since they are all tied, we’ll start with this one” and watch as they freak out.
From those grades you can devise an average and prioritize your backlog accordingly. It is useful to have registered the grading each of the stakeholders attributed for later comparison.
Press F for… Fibonacci
This option is somewhat familiar to those who already work with teams that do planning poker using Fibonacci. You interview your stakeholders, give them all the cards, explain why agile teams use Fibonacci and start a poker to define value for each product backlog item.
That will work well if your stakeholders have sufficient time to spare, are amiable to each other and have a close relationship to you. Just remember, if you start measuring value in Fibonacci (or any other method), you will have to do so throughout the backlog using the same measuring unit, or prioritizing by value will be impossible.
RUT is not a girl, but she’s your friend
After being successful in most attempts of using 1–10 grading and Fibonacci, I decided to focus my attention in the cases where I had no currency measure, and those methods were not helping either. I remembered using a prioritizing method called GUT years before, and tried it again, but it didn’t help as I expected.
As the pragmatic little thing I am, I decided to make adaptations to GUT, thus creating RUT, a good friend of mine to this day.
The reason RUT works in scenarios other prioritizing methods don’t is because RUT forces you and your stakeholders to honestly evaluate each aspect of the PBI (product backlog item), and rank them to specific definitions, minimizing the subjectiveness in the process. This is how it works.
For each PBI, you will create 3 columns: Relevance, Urgency and Tendency, and in each column you will answer a question about that item choosing 1 of the 5 possible answers below.
Relevance: how important is this item?
1 = it’s not important. It would be nice to have, but we’ll be fine without it.
2 = desirable, nice to have
3 = important
4 = very important
5 = it’s vital and highly valuable
Urgency: how immediate must the implementation be?
1 = implementing now makes no difference. We can wait.
2 = it’s not comfortable, but we can wait.
3 = it’s very uncomfortable, important to have in the next release.
4 = it’s urgent, we’ll have problems if this isn’t in the next release.
5 = it’s unnerving, urgent, and we cannot afford not releasing this item ASAP.
Tendency: As time goes by without this implementation, how bad does the situation get?
1 = the first impression is not good, but you can get used to it.
2 = it could be troublesome to keep going without it.
3 = we will have problems by not having this after a while.
4 = the longer it takes, the more problems we’ll have.
5 = it gets worse everyday, it’s extremely wearisome
You ponder and register the outcome, and then multiply all three. The result should look somewhat like this:
Later on, you can divide value per effort and come up with a way of prioritizing your backlog including the cost a certain feature will represent. That will also help in identifying which items should be done first.
But most of all, you must find ways to validate these attributes after implementation (using tools from analytics to polls) and offer feedback to your stakeholders so you’re able to show them if their perception of value is resulting in real aggregated value to the product.