Stack ranking vs. scoring: making prioritization decisions stick

Prioritization frameworks promise objectivity. Score every request on value, effort, risk and urgency, multiply by weights, and the right order appears. In practice, scoring often produces a list where twelve items are "priority 1," and the arguments start again the moment capacity runs short.

The problem isn't scoring. It's that scores alone don't force a choice. Stack ranking does. Used together, they make prioritization decisions that hold.

Two different tools

Weighted scoring assigns each item a score from a set of criteria. It's good at:

• comparing very different kinds of requests on a common basis;
• making the reasons for value explicit;
• spotting items that score low on everything.

Stack ranking puts every item in a single ordered list: 1, 2, 3, with no ties. It's good at:

• forcing a decision when items are close;
• making capacity allocation simple, by working down the list;
• making trade-offs visible: moving one item up moves another down.

Why scoring alone doesn't stick

• Scores cluster. With a 1 to 5 scale, many items end up with similar totals. Close scores invite endless debate.
• Weights become political. Whoever controls the weights controls the outcome, so weight discussions become proxy wars.
• False precision. A score of 3.8 versus 3.6 looks meaningful and isn't.
• Scores don't account for sequencing. Some items unlock others; a pure score misses that.

Why stack ranking alone isn't enough

A stack rank produced from gut feel is fast but hard to defend. When someone asks why their request is 14th, "the committee felt that way" isn't a satisfying answer. Without consistent criteria, the rank also changes every time the room changes.

Combining them

The most durable approach uses scoring to inform and ranking to decide:

1. Score every item on consistent value and complexity criteria. See IT portfolio prioritization.
2. Generate a starting order from the scores, for example value relative to complexity.
3. Adjust the order in discussion, for sequencing, dependencies, strategic bets and urgency the scores don't capture.
4. Record the reasons for any item that moves significantly from its score-based position.
5. Draw the capacity line. Items above it are committed; items below it wait.

The score gives everyone a common starting point. The rank is the decision. The recorded reasons make it defensible.

The capacity line makes it real

A ranked list only matters if it governs what gets worked on. Draw a line where available capacity runs out:

Now any new request has a clear question: where does it rank? If it ranks above the line, something else falls below it. That trade-off is visible and explicit. See IT capacity planning.

Keeping the ranking stable

• Re-rank on a cadence, monthly or quarterly, not every time someone asks.
• Allow emergency changes only through the forum, with the displaced item named explicitly.
• Separate support from investment. Urgent production issues shouldn't enter the investment ranking; they draw on reserved capacity for unplanned work.
• Keep one list. Separate lists for "IT projects" and "business projects" hide the trade-offs between them.

What about WSJF and other formulas?

Weighted shortest job first and similar formulas are scoring methods with a built-in bias toward small, urgent, valuable work. They can be a good starting point for the order. The same principle applies: use the formula to start the conversation, then rank deliberately and record why.

How Aizu helps

Aizu rates initiatives on consistent five-point value and complexity scales and plots them so the portfolio can be compared at a glance, with items lacking ratings clearly marked. Initiatives sit on a roadmap horizon such as now or next, and approval decisions are recorded with their rationale, so when an item moves ahead of its score, the reason is kept with it. Related: What leadership needs in a portfolio review.