Salesforce Backlog Prioritization: Why RICE and MoSCoW Quietly Bury Technical Debt

Most Salesforce backlog prioritization runs on a framework borrowed from product management - RICE, ICE, or MoSCoW - and every one of those frameworks was built to answer a question that isn't the one a platform backlog actually needs answered. They ask how many people want this and how confident are we it'll land. None of them ask whether the cost of leaving something alone is about to get worse. That gap is why the untested nightly batch job and the sharing rule nobody fully understands keep losing to a dashboard tweak a VP has now asked for twice - sprint after sprint - until something breaks and an incident reorders the backlog for you.

The short answer

In brief: RICE, ICE, and MoSCoW aren't wrong for Salesforce backlog prioritization, they're incomplete. Add one more scored criterion - platform risk, meaning how much worse this gets if it waits two more sprints - and give anything that scores high on it a minimum priority floor, regardless of how quiet or unpopular the request looks next to everything else. That single addition is usually enough to stop technical debt losing by default. If nobody currently has the technical visibility to make that call with confidence, a Salesforce Health & Roadmap review is one way to get an outside, defensible read on which items are genuinely platform risk before the next planning session argues about it again.

Why RICE, ICE, and MoSCoW undercount platform risk in backlog prioritization

RICE scores Reach, Impact, and Confidence, then divides by Effort. ICE trims that to Impact, Confidence, and Ease. MoSCoW sorts requests into Must, Should, Could, and Won't by business priority. All three are, at heart, asking the same question in different words: how much do people want this, and how sure are we? That's exactly the right question for a customer-facing feature backlog, where the cost of waiting is mostly flat - a feature not built this sprint is usually just as easy to build next sprint. It's the wrong question for the part of a Salesforce backlog that isn't a feature request at all: a Flow nobody's reviewed since it was built, an integration job with no monitoring, a sharing rule three exceptions past what anyone can explain. None of those score well on Reach, because 'reach' usually means people actively asking, not the number of records that would be affected if the thing failed silently overnight. They don't disappear from a properly-run backlog. They just consistently lose.

Your backlog already has a hidden scoring system

Salesforce's own admin community has already named what fills the gap when there's no real framework: whoever asks the loudest, or holds the most seniority in the room, wins by default. A backlog is supposed to replace that with something visible and fair. But a framework that only measures visible demand doesn't remove that bias - it just gives it a number to hide behind. If a VP's dashboard request scores an 8 out of 10 for reach and confidence, and the SAP sync job with no documented owner scores a 3, running both through the same formula didn't fix the loudest-voice problem. It endorsed it.

A worked example: the same three items, two scoring methods

None of this is abstract once real items sit side by side. Here's a standard reach-and-impact score set against the same three items scored with platform risk added as its own column:

The middle item loses under a standard score almost every time - not because it matters less, but because nobody is emailing about it. It's also the item most likely to become the incident that reorders next quarter's entire backlog for free, at a cost several times what fixing it proactively would have taken.

Three questions that actually measure platform risk

1. Does the cost of fixing this grow the longer it waits? Technical debt accrues interest; most feature requests don't. If the honest answer is 'about the same either way,' it isn't a risk item - score it on business value like everything else in the backlog.
2. Does this depend on one person's memory instead of documentation? An item only one person can explain is a standing single point of failure no matter how small the fix looks on paper - see what that risk actually costs when that person leaves.
3. What's the blast radius if this fails silently? A broken dashboard field is visible within the hour. A sharing rule or integration job failing quietly might not surface for weeks - by which point it's touched every record that passed through it, not just the one somebody happened to notice.

Why not just switch to MoSCoW or the Eisenhower Matrix instead?

MoSCoW and the Eisenhower Matrix have the same blind spot from a different angle, not a fix for it. MoSCoW still needs someone to nominate the SAP batch job as a 'Must,' and nobody nominates a problem they don't know is dangerous. The Eisenhower Matrix separates urgent from important, but an item with no active failure yet reads as 'not urgent' right up until the day it is. Swapping frameworks doesn't close that gap, because the blind spot was never in the math - it's in what gets measured in the first place. Adding platform risk as its own scored criterion works alongside whichever framework you already run, RICE included, because it forces someone to answer a question the other criteria were never designed to ask, instead of trading a framework your team already trusts for an unfamiliar one with the identical hole in it.

Who should actually own the platform-risk score?

Not whoever submitted the request, and not a committee vote - platform risk needs one person, or a small standing group, with enough technical visibility to say 'this genuinely gets worse if we wait' and defend that call when a stakeholder pushes back. In a lot of the growing organisations this matters most for, that's the same admin or developer already running the backlog day to day, which works fine as long as their risk calls aren't quietly overruled every time someone senior disagrees. Where that keeps happening, or where nobody currently has the technical depth to make the call with confidence, bringing in outside architecture judgment - through something like Salesforce Expertise as a Service - is usually cheaper than the incident a wrong call eventually causes.

Frequently asked questions

Do we need to replace RICE entirely?

No. For the genuinely visible, feature-shaped part of a Salesforce backlog, RICE, ICE, or MoSCoW work fine as they are. The fix is adding a platform-risk check for the items that aren't feature requests, not discarding a framework your team already trusts for everything else.

How often should platform-risk items be re-scored?

At minimum every planning cycle - not scored once and filed away. A low-risk item can become high-risk the moment something else in the org changes around it: a new integration touching the same object, a departure that removes the one person who understood it. Treat platform risk as a number that moves, not a label that's applied once.

What if leadership overrides the risk score anyway?

That's a legitimate business call, not a process failure - leadership is allowed to decide a visible commercial deadline outranks a risk item this particular sprint. What matters is that the override is visible and recorded, not that it never happens. A risk score that gets silently ignored every time creates the appearance of governance without any of the substance, which is worse than not scoring risk at all.

The bottom line

A backlog scored purely on visible demand will always look reasonable in the planning meeting and still produce an outage eventually, because visible demand and growing risk are rarely the same list. Adding platform risk as an explicit, honestly-scored criterion doesn't slow down feature delivery - it just stops the integration job nobody's watching from losing to the same dashboard request for the eleventh sprint running. If you're not sure how much of your current backlog would score high on that criterion, that's exactly the gap a Salesforce Health & Roadmap assessment is built to surface before it surfaces itself. Talk to an architect if a handful of specific items are worth a second opinion first.