Every prioritization framework looks clean in a slide deck and falls apart the moment it meets a real backlog of 80 half-described tasks. The frameworks don't fail because they're wrong — they fail because nobody keeps scoring tasks against them past week two.

The fix isn't a fancier framework. It's a small one you'll actually keep using.

Four criteria are enough

Most teams over-engineer prioritization with seven-dimension scorecards that take longer to fill in than the task takes to do. Four criteria cover almost every real decision:

  • Impact — how much this moves the outcome you actually care about.
  • Effort — rough size, not a precise estimate. Small / medium / large is enough.
  • Urgency — does waiting cost something, or can this sit for a month with zero consequence.
  • Dependency — does something else block on this, or does this block something else.

Score each 1–3, multiply impact by urgency, divide by effort, and sort. You don't need a spreadsheet macro — you need a rule everyone applies the same way.

Dependency beats impact more often than people think

Teams routinely rank by impact and effort alone, then get blindsided by a low-impact task that was secretly blocking three high-impact ones. If a task unblocks others, its priority isn't really 1–3 — it inherits the priority of everything downstream of it. This is the single most common reason "objectively prioritized" backlogs still produce the wrong order of work.

This is also why prioritization is fundamentally a graph problem, not a list problem: you need to see what connects to what, not just a sorted column of scores.

Re-score on a schedule, not when it's already too late

A priority score is a snapshot of what you knew when you wrote it. New information — a customer escalation, a dependency that turned out to be harder than expected — invalidates old scores silently. Re-scoring the top of the backlog every one to two weeks catches drift before it turns into a fire.

Make the score visible next to the work, not in a separate doc

If your prioritization scores live in a spreadsheet disconnected from where the actual tasks are tracked, the scores rot within a sprint — nobody updates a document they don't look at daily. Keeping priority, impact, effort, and dependencies attached directly to the task, on the same board where status changes happen, is what keeps the framework alive instead of becoming an exercise everyone did once.