Prioritization is crucial for a project to succeed. We need to make sure that we deliver what’s most important, what adds more value. The interesting and most challenging part of this is when we have to ask the business (client, product owner) to prioritize items. By calling them items I mean they are not necessarily stories, features or a product backlog. Sometimes we want to prioritize needs, purpose, goals and outcomes as well. The way we ask them is the trick…
I’ve seen many different ways of defining the priorities and usually there are ranges involved, sometimes with labels or numbers, like:
- Very High / High / Medium / Low
- Must Have / Should Have / Could Have
- Essential / Important / Not very important
- 1 - 5
There is nothing wrong with creating the labels, but when we ask the priority of one item only, that’s what happens sometimes:
How do we understand business priorities
The most effective prioritization exercise I’ve seen was to give the business a randomized list of items we want to be prioritized, then we ask them to give us the X most important items. And these will be the ones considered during the next timeframe. We should always let the list visible to the stakeholder who is prioritizing… It has to be clear for him that he is giving up on items in favor or others… at least for the next timeframe, which could be the next iteration of release.
It’s like a son’s birthday gift…
Good parents apply this rule with their children. Let’s say it’s close to my son’s birthday, I don’t have a son, this is totally hypothetical :), but my mother used this rule with me… So, I want to buy him a gift, ONLY ONE, of course, because I’m not the kind of dad that gives everything that my son wants. So I have a list of gifts that I know my son wants. Bike and video game are top of the list, but I can give him only one now, because it’s his birthday. We all know It’s close to Christmas (next iteration/release) and I will give him the other one on Christmas, but now it’s his birthday time, only one gift… I, then, make sure that my son understands the one gift per event rule and ask him which one does he want as his birthday gift… As a clever boy, he will think carefully which one really matters more to him because it’s clear that he has to give up on one in favor of the other. He will not give up on it forever though, it’s just until Christmas (next iteration/release), however, he knows that one of them will be bought and received first, and the other will come later…
As I said, there is no problem in defining labels and priority buckets, the only thing we have to bear in mind is that whenever we ask the business to prioritize items, we do not ask them in which bucket he wants to put one single item. And that’s when the principle comes.
Principle of Relative Priority:
All the decisions about item priority have to involve other items which are being traded in favor or the most important one(s). There is no absolute priority, only relative to other items.
One item by itself is usually important, otherwise it would not even be in the wish list… If I ask my son:
- Dad: “Do you want a bike?”
- Son: YES!
- Dad: “Do you want a video game?”
- Son: YES!
But when they have to CHOOSE… That’s when the most important items are picked… And during times of crisis, like now, with budgets constraints, we don’t even know if we will be able to afford a Christmas gift, so let’s make our kids happy during their birthday…
Technical
Agile, Cool, GFC, IterationMgmt, Prioritization, Scrum
As you can see, you can also make sure that your build time does not exceed a particular time that you can define using:
What this does is basically ping the page from the href and check if the http response is 200 (success). Simplicity! 
One interesting thing that came out of our retro was that the High Return section was almost empty. We came to the conclusion that this was a good sign, it means that we had already fixed most of the LowEffort/HighPain debt during the normal development. Which is exactly how this type of debt should be paid.
