Stop me if you’ve experienced this before.
You’re sitting at your desk staring at the 1,000 items in your backlog. How on earth can you possibly decide which one you’re going to do first?
Overwhelmed by the sheer number of things you could do, you end up defaulting to doing the thing requested by the director who screams the loudest. Now you’re under the gun to deliver a feature to an unrealistic date the director pulled out of thin air.
If only there was a framework you could use to determine which items to do first…
There are too many prioritization frameworks
There are several frameworks you can use to prioritize features.
Some frameworks have you score each feature based on a set of criteria. You then add the score up for each feature and then rank the features based on their scores. Voila! You have a stack ranked list.
Other frameworks have you group features based on some sort of criteria, or map them on a 2×2 matrix. Then there’s guidance which group or quadrant you work on first.
I didn’t mention any of those frameworks here because I don’t want to encourage you to use them.
These frameworks may give you the appearance of an objective approach, they’re all fooling you. In order to come up with a score, or pick which group to put a feature in, you’re making a subjective choice.
Besides, all of those frameworks have an implicit assumption that the features you’re picking from aren’t related to each other.
And if that’s true, that may be your first problem.
Don’t start with a list. Start with an Outcome
If you face a 1000 item backlog, your first step should be to burn the backlog.
Then, understand what you’re trying to accomplish with your product and identify the things that you need to do in order to reach that outcome.
Then, base your priority decisions based on what you need to do to reach that outcome. The multitude of prioritization frameworks out there will not tell you the answer.
Feedback from users and stakeholders, and experiments to validate assumptions are.
It may seem messy, but it will end up with a better result in the end.
Why You Should Avoid Prioritization Frameworks and How To Do It Right
Saeed Khan explains why you should prioritize based on objectives and strategy, not spreadsheets and formulas.
Priority Starts at the Top
Prioritization methods are based upon the notion of Value, but given the sort of questions people struggle with, it clearly is ill-defined for many.
Here’s the deal: Value comes from Outcomes, not Outputs.
So, how do we tackle the issues mentioned at the outset? How do we use an outcomes-based lens to avoid prioritization problems?
Measuring business value is not the points
Agile coaches are infamous for answering the “how do you prioritize?” question by the accurate, but completely useless answer “prioritize by business value.” That answer is useless because most struggle to pinpoint what “business value” is in any practical sense.
A technique that became popular in agile circles was the idea of business value points – borrowing from the concept of story points, but measuring relative value instead of relative effort.
Sounds good on the surface, but it doesn’t work well in practice.
Prioritization is a Political Problem as Much as an Analytical Problem
Prioritization is more than an analytical/intellectual exercise. It’s an organizational challenge with natural disagreements among stakeholders. Product leaders need to think about motivating the right kinds of participation and addressing the emotional issues that arise. Spreadsheets and models are necessary, but not sufficient.