Performance: More = better satisfaction; linear relationship
Excitement (Delighters): Unexpected; creates delight; absence is neutral
Indifferent: Users don't care either way
Reverse: Some users want it, others don't
Recommend building: all Basic features first → Performance features for key use cases → 1–2 Excitement features per release.
Programmatic Helper
This skill ships with a stdlib-only Python script that computes ranking for the math-based frameworks (RICE, ICE) so feature scoring is consistent across sessions.
# RICE from JSON
python3 scripts/feature_prioritisation.py initiatives.json --framework rice
# RICE from CSV
python3 scripts/feature_prioritisation.py initiatives.csv --framework rice --format csv
# ICE from JSON
python3 scripts/feature_prioritisation.py features.json --framework ice
# Pipe into it
printf '%s\n' '[{"name":"API refactor","impact":8,"confidence":80,"ease":5}]' \
| python3 scripts/feature_prioritisation.py --framework ice -
Use --json to produce machine-readable output for downstream tooling.
Always anchor prioritisation to a specific goal or metric — never prioritise in a vacuum
Flag when two features have similar scores but very different risk profiles
If stakeholder politics are influencing prioritisation, name it explicitly and suggest separating the framework score from the final decision
Recommend revisiting priorities every 2 weeks minimum
Never produce a single-column ranked list without rationale — explain the top 3 and bottom 3 decisions
Deeper Materials
This skill ships with support files — use them when they are available:
references/framework-selection.md — Picking the Prioritisation Framework (Instead of Defaulting to RICE). Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
templates/prioritisation-session.md — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.
Scoring Rubric (0–40)
Score any output of this skill before handing it over; 32+ is ship-quality.
Dimension
0
5
10
Goal anchoring
No stated goal, or items silently scored against different objectives
A goal is named but individual scores don't reference it; off-goal items scored anyway
One explicit metric and scope; every score justified against it; items serving a different goal ejected with instructions to resubmit
Scoring integrity
Frameworks mixed in one session, arithmetic wrong, or scales invented mid-table
One framework applied consistently, but confidence defaults high and scale anchors are undefined
Consistent framework, verifiable maths, defined impact anchors, confidence honestly reflecting the evidence behind each estimate
Transparency of cuts and assumptions
Cut items simply vanish; no record of estimates or their sources
Deprioritised items listed but without reasons; assumptions partial or unsourced
Every cut carries a reason and revisit trigger; assumptions name their sources (analytics, engineering estimates) so the ranking is re-runnable
Judgment beyond the number
A sorted table presented as the decision
Top picks get rationale, but near-ties, risk profiles, and politics go unmentioned
Near-ties broken on risk with reasoning shown; political pressure named with framework score separated from final decision; top and bottom of list both explained
Quality Checks
Every item is scored against the same goal or metric (not different goals per item)
Deprioritised items are explicitly listed with reasons (not just absent from the ranked list)
Assumptions used in scoring are documented
Stakeholder politics or personal preferences are separated from framework score
Prioritisation is anchored to a specific scope (sprint / quarter / launch)
Anti-Patterns
Do not score items against different goals — every item in a prioritisation session must be scored against the same objective
Do not omit deprioritised items — explicitly listing what was cut and why is as important as the ranked list
Do not let stakeholder politics override framework scores without documenting the override and reason
Do not mix RICE, ICE, or MoSCoW scores across frameworks in a single session — pick one framework per prioritisation exercise
Do not treat the output as final without documenting the assumptions used in scoring — assumptions change, and the list must be revisitable
