If you’ve ever prioritized a large backlog, you may have seen the RICE framework in action. The acronym stands for R each, I mpact, C onfidence, E ffort, and it’s a simple formula for determining the weighted score of a backlog item.
So is RICE a good tool for agile backlog prioritization?
In my view: No
Why?
Well, it’s not an inherently bad tool. It’s just too heavy for truly agile work.
If your team’s goal is agility, then you should generally be prioritizing the minimum number of tasks possible. That usually means just enough tasks for everyone to have work for the day, or if you’re using Scrum, for the sprint, and nothing more. The reason not to prioritize more is that, if your goal is agility, by the time you’re ready for a new task, you’ll have new information and new priorities anyway, so any prioritizaion you had done a day or a week or a month ago will be irrelevant now.
With this in mind, it’s usually pretty clear what the single most important thing is to work on for the day or for the week. You don’t need a 4-variable framework to make such a decision.
If you do find yourself in a situation where you have two tasks of seemingly equal urgency, select the faster one. If they seem to be of the same size, pick an arbitrary one.
If you find yourself in a situation where you have a whole pile of tasks of equal urgency and size, this probably means you’re just looking at a big bag of bugs, and none of them are really very urgent at all. If you must, start on an arbitrary one. Better yet: Determine if your team could/should be working on something more urgent.
All this to say: If your goal is agility, you should be changing priorities frequently enough that planning more than one or two tasks ahead is a complete waste of time. In such a scenario, RICE, or practically any other prioritization framework, is just wasted effort.
If you enjoyed this message, subscribe to The Daily Commit to get future messages to your inbox.
Top comments (0)