Should we use RICE to prioritize our agile backlog?

October 10, 2021

If you’ve ever prioritized a large backlog, you may have seen the RICE framework in action. The acronym stands for Reach, Impact, Confidence, Effort, 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


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.

Related Content

Why I don't like Jira

I believe Jira is responsible for more lost human productivity than any other software ever created. And yes, that's even when considering Windows Me!

Agile houses

We often contrast software to physical buildings--the idea that software is easy to change, whereas buildings are difficult to change. But is this really true?

Pick a methodology: Scrum, Kanban, XP, Lean or DevOps?

None of these items directly replaces or conflicts with any of the others. In fact, you can use them all simultaneously.