ICE scoring is a prioritisation framework that ranks backlog items by multiplying three factors: Impact, Confidence, and Ease. Each is scored on a 1–10 scale. Multiply them together and you get a number out of 1,000. The highest scores rise to the top of your list. It takes minutes to apply and requires no specialist tools — which is both its biggest strength and its most important limitation.
What Impact, Confidence, and Ease actually measure
The three factors sound straightforward. In practice, each one contains a decision you need to make explicitly before scoring.
Impact asks: if this initiative works exactly as intended, how much does it move the metric that matters? A score of 10 means it directly drives your primary north star metric — revenue, activation, retention, whatever you are optimising for. A score of 1 means it might have a marginal effect, or it affects a metric three steps removed from anything the business cares about. The key word is “if it works.” Impact is scored optimistically, on the assumption of success.
Confidence asks: how sure are you that it will work? This is where you factor in evidence. Do you have user research? Experiment results? A comparable case from another product or market? Score 10 if you have strong data. Score 5 if you have anecdotal evidence or a reasonable analogy. Score 1 or 2 if you are guessing. Confidence is the most honest factor — and the one teams most often inflate.
Ease asks: how little effort does this take? A score of 10 means you could ship it this week with one engineer and no design work. A score of 1 means it requires a platform change, three teams, and a migration. Ease is the inverse of effort: high ease, low effort. One consistent mistake is letting the person proposing the idea score Ease — they almost always overestimate it.
How to calculate an ICE score: a worked example
Imagine you are a PO at an ecommerce company and you have three items competing for the next sprint. You score each against Impact, Confidence, and Ease on a 1–10 scale:
A: Add guest checkout — Impact 9 (directly reduces checkout abandonment), Confidence 8 (you have data showing 30% of drop-offs are on the account creation step), Ease 6 (one sprint, one engineer). ICE = 432.
B: Redesign the homepage hero — Impact 5 (brand perception, hard to link to revenue), Confidence 3 (no evidence this drives conversion), Ease 7 (design already done). ICE = 105.
C: Fix mobile payment form layout — Impact 7 (mobile accounts for 60% of traffic), Confidence 7 (QA logs show clear friction), Ease 8 (a CSS fix). ICE = 392.
Guest checkout goes first. Mobile payment fix goes second. Homepage hero goes back into the backlog for further evidence. The scores did not make the decision — they made the decision easier to defend.
When ICE works well
ICE was popularised by Sean Ellis in a growth context — the same world that gave us growth hacking and North Star metrics — and that origin still tells you where it belongs. It performs best when you have a large number of small-to-medium experiments competing for limited resource, and when speed of decision matters more than depth of analysis.
It is particularly useful in three situations. First, early-stage products where you have no historical data and need a structured way to choose between guesses. Second, growth teams running a high volume of A/B tests or feature bets, where spending an hour per item in analysis would defeat the purpose. Third, any situation where you need to get a team aligned on relative priority without convening a workshop — ICE gives everyone a shared language and a visible rationale.
ICE scoring does not replace judgement. It creates the structure that makes judgement faster.
Where ICE falls short
The lightness that makes ICE fast also makes it brittle. Three problems come up repeatedly in practice.
Scores are subjective and unstable. The same person scoring the same item a week later will often give different numbers. Without calibration — agreeing as a team what a 5 for Impact or a 7 for Ease actually means in your specific context — ICE scores are not comparable across items or across time. This is not a reason to avoid ICE, but it is a reason to treat it as a conversation starter rather than an objective ranking.
It does not account for strategic fit, dependencies, or risk. An item can score 600 on ICE and still be the wrong thing to build — because it pulls you away from your current focus, because it creates technical debt in a system you are about to replace, or because it is contingent on three other items that have not shipped yet. ICE is a single-dimension filter, not a full prioritisation system.
Ease is almost always scored by the wrong person. The engineer who will build the feature needs to score it, not the PO who proposed it. If you cannot get an engineering estimate before scoring, mark Ease as provisional and revisit it after refinement.
ICE vs other prioritisation frameworks
ICE sits at the lightweight end of the prioritisation spectrum. If you need more rigour — particularly if your decisions involve significant cost of delay, regulatory risk, or cross-team dependencies — WSJF gives you a more structured model. If you are in a high-volume growth context and want to add audience Reach as a fourth variable, RICE is ICE’s more thorough sibling, adding the size of the audience you’re actually reaching into the equation.
If you are not yet sure which framework fits your situation, Product Prioritisation Techniques and When to Use Them covers all the major methods — MoSCoW, WSJF, RICE, Kano, and ICE — and the specific circumstances where each one earns its place.
TL;DR: ICE scoring ranks backlog items by multiplying Impact, Confidence, and Ease — each scored 1–10. It is the fastest prioritisation framework to apply, which makes it ideal for growth teams, early-stage products, and quick-filter decisions. Its main limitations are subjectivity and a lack of strategic context. Use it to start the conversation, not to end it. Written by Delphine Ragazzi.
