One Tool to Consider When Tackling the Dreaded Backlog
It doesn’t matter if you are a startup, a company that has found your product-market-fit, or you have found business-model-fit…chances are you still have a backlog prioritization problem. These problems come in all shapes and sizes: an unruly backlog, a lack of clarity on the things in your backlog, duplicate user stories/features, no level of urgency or importance, nobody owning the backlog, no prioritization, no decision makers, no business objectives to guide the roadmap…you get the idea.
The list is endless. If you have ever interacted with a backlog, I guarantee you have felt more than one of these pain points.
This blog post will talk about ONE tool we used and the scenario in which we used it. It’s not a silver bullet or a one-size-fits-all, but it is a tool that should go into your toolbox. We may even circle back in future blog posts to talk about other tactics you can employ to get that backlog back under control or how to jump-start your backlog. But I digress, back on topic.
Let’s talk about RICE scoring. RICE stands for Reach, Impact, Confidence, and Effort. It’s a formula that gives you a score for whatever you’re measuring (in our case, backlog items) and then provides a metric to help you prioritize.
Let me highlight something: it HELPS you; it is not the end all be all. Other prioritization tools and calculations are out there – some folks will swear by them, others might tell you that you are wasting your time. I will tell you, it’s a tool and should be employed in the right environment. It is merely a starting point, a conversation starter, or something you can use to give more weight to a discussion.
You can read more about how to calculate this metric here. Notice that some of the information you are looking for could vary depending on where the product is at in your product lifecycle. Are you a startup trying to find problem-solution-fit? Or maybe product-market-fit? Your variables may be less known; maybe you have a mature product, and these variables are known. The confidence factor will help you weigh your results.
The other thing you will need to make this work is the denominator value, ‘Effort.’ There is a critical piece here – a good understanding of the user story requirements is a must. If you don’t have that, your Architect will have a hard time providing a reasonable WAG (wild-ass guess). Requirements can help provide you with a better estimate within that cone of uncertainty. Don’t have a relationship with your engineering team? Time to make friends!
Now, let’s talk about implementation. As mentioned, you can use this in several scenarios. We used it on a product reinvention project; the scope was MASSIVE, and we needed help. Help to determine which features were critical, which features we could go MVP on, and which features might be worth a scope cut discussion. The best part? We knew the user base numbers (reach), modified impact to be very specific to the work these users were doing, and confidence turned into a product-market-fit metric instead of how confident we were in our Reach and Impact (known factors). Effort? That was easy peasy because we have some awesome architects and product managers.
The result provided us with things we could cut scope on, areas we needed to make sure we pulled out all the stops, and areas we knew could truly be MVP. The end result helped us align with our stakeholders and our internal teams. In a sea of features, development, UX, product, and QA were now armed with a way to make more informed decisions at a tactical level.
Backlog prioritization is not a one-size-fits-all; it depends on your product and the unique pain points you are solving. Take a look at RICE scoring, don’t be afraid to modify the formula to meet your needs, and remember that it’s meant to aid you, not make your decisions. Happy backlogging.
