prioritization_frameworks v1.0.0

name: prioritization_frameworks description: "Pick and run the right prioritization framework for a real backlog: a selection diagnostic for ICE, RICE, Kano, MoSCoW, WSJF, and Opportunity Score, a facilitated scoring-session protocol, bias traps with detection tests, sensitivity checks, and a runnable scorer. Use when someone must rank features, experiments, projects, or requests, choose between frameworks, run a scoring session, scope an MVP or release, or defend a ranking to stakeholders."

Prioritization Frameworks

Purpose

Help a team rank competing work honestly. The hard part is rarely the arithmetic. It is picking a framework that fits the decision in front of you, scoring without gaming the inputs, and knowing where the result stops being trustworthy. This skill covers that applied work. For roadmap formats and stakeholder communication of a finished plan, use the product-roadmapping skill instead.

Workflow

1. Name the decision before naming a framework. Write down, in one sentence, what the ranking will decide: which experiments run next, what ships in a fixed-date release, what order a portfolio gets funded, or where unmet need is largest. A framework that answers a different question gives a confident answer to the wrong problem.

1. Run the selection diagnostic. Match the situation to a starting framework. Full detail and failure modes: references/frameworks-and-lies.md.

• Many ideas, little data, decision needed today: ICE. Impact, Confidence, Ease, each 1 to 10, averaged.
• Usage data exists and items affect very different numbers of people: RICE. (Reach x Impact x Confidence) / Effort, effort in person-months, impact on the 0.25 to 3 scale, confidence as a percent.
• A fixed date or a fixed release scope is the real constraint: MoSCoW. Must, Should, Could, Wont have this time. Keep Must effort at or below about 60% of the release.
• Delay itself has a cost you can describe, such as a deadline, a closing window, or risk that grows over time: WSJF. Cost of Delay / Job Size, with Cost of Delay scored relatively across business value, time criticality, and risk reduction.
• You need to know what kind of satisfaction a feature creates, not just how much: Kano. Paired functional and dysfunctional survey questions classify items as must-be, performance, attractive, indifferent, or reverse.
• You have survey data on outcomes and want to find underserved needs: Opportunity Score. Importance + max(Importance - Satisfaction, 0), both on 1 to 10 scales.
• The items differ on several criteria the group genuinely cares about and no single formula fits: weighted scoring, with weights agreed and written down before anyone scores.

1. Calibrate before scoring. Pick two anchor items together: one the group agrees is high on the main scale and one that is low. Score those first, out loud, with reasons. Every later score is relative to the anchors. For effort, anchor on finished work: name a past item that took one person-month and compare against it. Estimates built from the details of the new item alone run optimistic; past outcomes for similar work are the correction.

1. Score independently, then reconcile. Each scorer scores alone and silently first. Collect the sheets, then discuss only the items where scores diverge by a wide margin. Discussion before independent scoring anchors everyone on the first voice in the room, often the most senior one. Record the final inputs and the reason for any input that changed after discussion.

1. Compute with the scorer, not by hand. Put the backlog in a CSV like assets/backlog-example.csv and run python3 bin/scorer.py backlog.csv. It ranks by ICE, RICE, WSJF, and Opportunity Score where the data exists, reports the MoSCoW Must share of effort, flags suspicious inputs, and stress tests the RICE leader. Use --framework rice (or ice, wsjf, opp) for one ranking.

1. Interrogate the result before accepting it. Work through the checks in references/scoring-session.md: close scores count as tied, the sensitivity check must hold or the top ranks get reported as a band, and any audit flag needs an answer. Then cross-check with a second lens. If two frameworks disagree, the disagreement is information: name what each one is actually measuring before picking a winner.

1. Decide, record, and set a review point. The score informs the decision; a person makes it. Log the decision, the inputs, the overrides and their reasons, and a date to re-score. Confidence should change as evidence arrives. A ranking that never gets revisited turns into a stale opinion with numbers attached.

Output Contract

When you run a prioritization for someone, return:

• The decision sentence from step 1 and the framework chosen, with the reason it fits.
• The scoring table: every item, every input, and the computed score. No score without its inputs.
• The ranking, with tied bands marked where scores are close (within about 10% for RICE).
• Audit flags and sensitivity results, and how each was resolved.
• Overrides: any place the final order differs from the score order, with the reason written down.
• The decision log entry and the re-score date.

Use assets/scoring-sheet.md as the session record template.

Operating Rules

• One decision, one primary framework. A second framework is a cross-check, not a second answer to average with the first.
• Never present a score as a measurement. RICE impact values and ICE 1 to 10 scales are ordered labels; multiplying or averaging them does not make small gaps meaningful. Treat close scores as tied.
• Confidence needs evidence. 100% in RICE means data, not enthusiasm. A room where every item scores 80% or higher is a room that has not scored confidence at all.
• Effort estimates include design, build, test, and rollout, and get compared against similar finished work before they enter a formula.
• MoSCoW Must is a test, not a label of importance: if the release fails without it, it is a Must. Everything else is not, however much someone wants it.
• Kano categories come from paired survey answers, not from a workshop opinion. Without survey data, call a Kano label a guess and treat it as one.
• Do not re-score quietly to reach a preferred answer. If an input was wrong, fix it, note the fix, and show the ranking before and after.
• Dependencies and hard constraints outrank scores. A lower-scoring item that everything else waits on goes first, and the log says why.