Scoring frameworks: impact effort matrix, RICE and more

“Ten out of ten” means nothing until someone says what a ten is. A prioritization framework fixes that: an agreed, repeatable way to rank items against the same criteria, so anyone can see how a score was reached.

The simplest one is the impact effort matrix, also called a value vs effort grid: a 2×2 with value on one axis and effort on the other. Each corner comes with its own instruction.

• Quick wins (high value, low effort): do them soon; a real gain for little work.
• Big bets (high value, high effort): plan them, split them into steps and test the riskiest assumption first.
• Fill-ins (low value, low effort): only when there's spare capacity.
• Money pits (low value, high effort): avoid them, or rethink the solution, however exciting they sound.

The grid is quick and easy to explain in a meeting. Its weakness is that “high value” is still a feeling. The next step is to score value against your objectives, so the corners rest on something people can check.

A value vs effort scorecard makes “high value” less of a feeling by scoring it against your objectives.

Value: for each objective, give the candidate 0, 1 or 2 (no effect, some, a lot), and add them up. Negatives are allowed: if a candidate hurts one objective, score it −1 there. Effort: T-shirt sizing is enough: XS, S, M, L and XL, counted as 1 to 5. Relative sizes, with no calendar attached, are easier for engineers to give honestly than days. Confidence: a risk discount, written as a fraction.

Score = value ÷ effort × confidence.

The online order form: 2 for clinics, 0 for subscribers, size S, 80% sure: 2 ÷ 2 × 0.8 = 0.8. The idea of Brandon, the key account manager, of letting clinic orders skip the warehouse queue helps clinics (+2) but makes subscriber boxes wait longer (−1). Value 2 + (−1) = 1, so 1 ÷ 2 × 0.8 = 0.4. The negative halves the score, and that's the point: a scorecard shows the cost to one group that a single “value” number would hide.

RICE scores one candidate against one objective: Reach × Impact × Confidence ÷ Effort.

• Reach: how many customers the item touches in a period, here per quarter.
• Impact: how far it moves each of them towards that objective's key results, on fixed steps: 3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal.
• Confidence: 100% for tested results, 80% for a clear pattern in data, 50% for a few requests or a hunch. Use it as a fraction: 0.8, not 80.
• Effort: person-months for everyone involved, not only engineering.

Flexible delivery dates: 1,500 subscribers × 2 × 0.8 = 2,400; ÷ 4 person-months = 600. One-click reorder: 1,200 × 1 × 0.8 ÷ 1 = 960. Apple Pay and Google Pay at checkout: 3,000 × 0.25 × 0.8 ÷ 0.5 = 1,200.

The fixed steps are what make RICE comparable: if every team invents its own impact scale, the scores mean nothing side by side. Agree the scales once, write examples next to them, and reuse them.

RICE scores only compare when they share a unit of reach. CatChow's clinic items count clinics (54 of them); its subscriber items count people (thousands). So every clinic item scores far below the subscriber items, not because it matters less, but because the units differ.

The online order form for clinics: 54 × 1 × 0.8 ÷ 1 = 43.2. Automatic reorders: 54 × 2 × 0.5 ÷ 3 = 18. The portal: 54 × 2 × 0.5 ÷ 6 = 9. Inside the clinic objective, that order means something: the pilot raised the form's confidence, and it's small.

Put 43.2 next to the 600 for flexible delivery dates, though, and the comparison is empty. Rank within each objective.

That leaves a question no score can answer: how capacity is split between objectives, for example most of the team on keeping subscribers and a fixed share on clinics. The split is a strategy decision, one of the choices behind the objectives in module 2, made before anyone scores. Scores then rank only inside each share.

When you check a row by hand, keep every factor, confidence included: it's the one most often dropped.

The same formula gives very different answers depending on who fills it in. The founders scored loyalty points with impact 2, confidence 100% and effort 2: 5,000 × 2 × 1.0 ÷ 2 = 5,000. The honest version is 5,000 × 1 × 0.5 ÷ 8 = 312.5, sixteen times lower and the lowest in objective 1.

Each input moved for a reason. Confidence is 50%, not 100%: the evidence is a few comments from long-term subscribers, and 100% is reserved for tested results. Impact is 1, not 2: points also reward people who were staying anyway, so much of the effect lands on subscribers you weren't going to lose. Effort is 8 person-months, not 2: two months is only engineering's part; add the points rules, finance, emails, support training and marketing.

Honest confidence and impact account for a factor of four; counting everyone's effort accounts for another four. 4 × 4 = 16.

That's why effort always counts everyone involved. A feature that is cheap for engineering can still be expensive for the company.

A RICE score multiplies four estimates, so the warning about false precision from Going deeper applies in full: the quiz (450) isn't clearly ahead of loyalty points (312.5). Round, call close scores a tie, or group them into high, medium and low.

The risk this lesson adds is gaming: whoever wants an item rates it high. The founders' ten out of ten is the classic case. Four guards keep scores honest:

• Define each step of the scale with an example from past work, so “impact 2” means the same to everyone.
• Score together as a group, not alone, so one person's enthusiasm meets others' doubts.
• Ask for evidence behind any confidence above 50%.
• Compare estimates with results after launch, so the team learns how good its guesses are.

Two habits make things worse: letting requesters score their own ideas, and showing scores to two decimal places so they look exact.

A score starts the conversation; it doesn't end it. Its real job is to show which estimates are worth arguing about.

Once every candidate is scored, the top of the list can surprise you. At CatChow, Apple Pay and Google Pay at checkout leads objective 1 with 1,200, ahead of everything that serves a theme. The arithmetic is right: it's tiny (half a person-month) and reaches 3,000 buyers. But its impact on the key results is minimal (0.25), and it serves no theme.

That's a quick win without strategic weight. Doing it when there's slack is fine, as a fill-in. Putting it first in Now, or filing it under “Subscribers never run out” to make the theme look stronger, would pass it off as progress on something it barely touches.

The bottom of the list needs the same care. The warehouse replacement scores 1.8, dead last. On its own it changes little for clinics, but like any enabling work it is judged by what it unlocks, so in time it goes first anyway.

A ranking is a picture of your estimates. Read it with the themes and dependencies beside it before you act on it.

RICE has no clock. It can't tell you that something loses value every week it waits. Cost of delay asks exactly that: what do we lose for every week this item isn't done? For CatChow's clinic solution, the conference on 23 May makes the loss concrete: if clinics can order online by then, Brandon can sign new clinics right at the stand.

WSJF, weighted shortest job first, puts cost of delay next to size: WSJF = cost of delay ÷ job size, and the highest ratio goes first. That way short, urgent work goes ahead of long work of similar value.

An example in relative points. Online order form: cost of delay 8, size 2, so 8 ÷ 2 = 4. Clinic portal: cost of delay 9, size 6, so 9 ÷ 6 = 1.5. The portal loses slightly more per month of waiting, but the form delivers its value much sooner, so it goes first.

Both inputs are estimates, so the same cautions apply as for RICE: agree the scales, score together and don't trust small differences.

The MoSCoW method sorts a release's scope into four groups: Must have, Should have, Could have and Won't have this time. It's a clear way to tell a team and its stakeholders what's in a release, what's optional and what's deliberately left out.

What MoSCoW doesn't do is decide which items deserve to be Musts. It has no criteria of its own. If people label items before the scoring is done, “Must have” simply records who argued hardest, and it becomes the same loud-voice ranking in a new format. The founders' sheet with “Must have” next to loyalty points is exactly that.

So use it in the right order. First set priorities with criteria from your objectives and with scores. Then use MoSCoW to communicate the scope of a particular release. And keep “Won't have this time” honest: it's a real answer, not a hidden Later.

How it fits together: Each tool answers one question: the matrix, where to look; the scorecard, trade-offs between objectives; RICE, order inside one objective; cost of delay and WSJF, what loses value by waiting; MoSCoW, what's in this release. None decides alone. Next: handling an answer that disappoints someone.