The RICE Prioritization Formula

RICE is a simple way to prioritize potential ideas and features to find which ones that are the best bang for your buck.

Using the formula and its results, you can compare items against one another to determine which ones you should tackle first and which ones may offer the greatest impact with the fewest resource costs. You may also find surprises in what you shouldn’t work on.

RICE consists of four parts: reach, impact, confidence, and effort. Each is measured in its own way.

Once an item is score on these four parts, it’s thrown into a formula and then boom! A wild RICE score appears!

Here’s the formula:

RICE = (Reach *Impact * Confidence) / Effort

Your job as a PM is to do the scoring and calculations required for RICE.

Once you’ve scored each item on your list’s potential reach, impact, effort, and confidence level, you’ll have a ranked list of the best next features for your product.

How to Use RICE In Practice

There are two ways to get setup with RICE.

Option one is to open up Speckled. Option two is to use the spreadsheet program of your choice.

If you’re in Speckled, all of this is already set up for you.

If you’re in a spreadsheet, you’re going to want to create 6 columns. One for the idea name and then more for reach, impact, confidence, effort, and RICE score.

Once you’ve done this, it’s time to list out all of your items you’re thinking of working on down the first left hand column.

When the list is complete, add scores for each item in your reach, impact, confidence, and effort columns. Then use the formula above to calculate each item’s RICE score. Sort by RICE score to find the “best” items (higher score is better).

A Quick Guide to Scoring Items with RICE

If you’ve never used RICE before, knowing what’s “high” impact vs “low” impact or about how big your reach is is an exercise in subjectivity. Below is a guide that will help you hone in the numbers that best reflect your situation.

The Elements of RICE

Reach

Measured as a number

Ex. 120

Reach is how many users will likely be impacted or touched by the item.

For new features, reach is typically how many people will actually use the feature. As PMs, we’d like to think that everyone is going to love our shiny new feature. However, setting our reach number to our whole user base count for every feature is going to throw off all our other estimates. Therefore it is best to estimate reach as realistically as possible. If your feature applies to a certain segment of your application, then you may want to use a portion of that segment instead of your whole user count.

Impact

Measured as high, medium, or low

Ex. Medium

Impact is how much of an effect this item is going to have on your users. This can be very subjective, and each item’s impact score may depend on other items it is being scored against.

Examples of low impact items:

• A bug fix that few people have reported
• A feature that has a use case not applicable to a majority of your users
• A bug fix or a new feature that will improve the application for a small number of users
• A feature that is unlikely to bring in new users or retain existing ones
• A bug fix that is preventing users from accessing your application and is easily worked around
• A UI/UX change that will make something a lot prettier but not more useful
• Code changes that will add unnecessary technical debt to the codebase

Examples of medium impact items:

• A feature that adds significant improvements, but will not likely be used by everyone
• A feature that may or may not bring in new users or retain existing ones
• A bug fix that is preventing users from accessing your application but could be worked around
• A feature that would effect around half of your user base
• A UI/UX change that will make something look better and make it more usable
• Clarifying copy
• Code changes that will clean up some existing technical debt

Examples of high impact items:

• Features that fundamentally change how your application works
• A feature that adds significant improvements for a majority of your user base
• A feature that will bring in new users or retain existing ones
• A critical bug fix that is preventing users from accessing your application or requiring unreasonable workarounds
• A UI/UX change that will delight and add to the usability of the application
• Clarifying copy that customers continually reach out to support to help understand
• Code improvements that will improve the code base for the future

Effort

Expressed as a number

Ex. 3

Effort is how long your team will need to pull this item off.

The unit of this number is up to you. For small teams, this could be measured in days. Medium teams may measure this in weeks, while large teams may use a month scale.

If you’re not great at estimating how long software will take to build (and hey, who is?), then it may be wise to get some input from the team on these scores.

Confidence

Expressed as a percentage

Ex. 95%

Confidence is an indicator of how sure you are of all your estimates above.

Know that button color change will take only a few minutes, its impact will be low, and it may impact 100 users? Your confidence score may be in the upper 90s.

Swapping out your entire payment processing system with a new one? It could take a couple of weeks or it could take months. It’s impact to your internal systems may be high, but to users it may be low. Reach is tricky and it may touch none of your customers or all of them if they land up needing to re-add their payment method. Confidence on this one may be much lower. Perhaps in the 30-40% range.

You’ll find RICE as a great gateway into prioritization beyond just using your gut or whatever pops into your head first. Give RICE and other prioritization frameworks a whirl in Speckled.