# Rice Prioritization

> Apply RICE / ICE / WSJF / MoSCoW prioritization frameworks when ranking multiple feature ideas, backlog items, experiments, or initiatives. Use whenever 用户 asks "哪个先做" / "这个值不值得" / "怎么排序" / "优先级排一下" / "rank these" / "should we do X first". Forces explicit scoring on Reach × Impact × Confidence ÷ Effort (RICE) or job size / time-criticality / risk-reduction (WSJF). Stops gut-feel prioritization, forces dimension-by-dimension reasoning, surfaces hidden Confidence assumptions, separates "feels important" from "scores high". Self-contained methodology — no external docs required.

- Skill: `marsloting/rice-prioritization` (Agent Skill)
- Install (CLI): `npx skillmds@latest add marsloting/rice-prioritization`
- Raw SKILL.md: https://api.skillmd.com/api/skills/marsloting/rice-prioritization/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: marsloting (https://skillmd.com/u/marsloting)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/marsloting/rice-prioritization

---


# RICE / 优先级评分

## 何时触发

- 用户 列出 ≥ 3 个待办 / 想法 / 实验 / 需求要排序
- "这个先做还是那个先做"类二选一以上
- "这个值不值得做" / "这个需求该不该接"
- backlog grooming / sprint planning 准备阶段
- 老板列了一堆"都很重要"的东西要消化
- 多个团队抢资源时的仲裁需求

## 何时不触发

- 单一选项是否做 → 用 pre-mortem 做正反推演
- 已有明确数据驱动的 A/B 实验排序 → 用 gtm-ops:growth-engine
- 紧急 hot fix 不需要评分（救火不是优先级问题）

## 默认框架：RICE（最常用）

```
RICE Score = (Reach × Impact × Confidence) / Effort
```

| 维度 | 含义 | 单位 / 范围 |
|---|---|---|
| **Reach** | 一个时间窗口内会被影响的用户数 | 具体数字（每月触达人数） |
| **Impact** | 命中后单用户的影响程度 | 3 = 大量影响 / 2 = 高 / 1 = 中 / 0.5 = 低 / 0.25 = 极低 |
| **Confidence** | 你对前三项估计的自信度 | 100% 高 / 80% 中 / 50% 低 / < 50% 不要做 |
| **Effort** | 团队投入（person-month） | 具体数字 |

**输出**：每个候选项一个 RICE 分数，按分数降序排列。不允许只看分数，必须列出 Confidence < 80% 的项哪些假设需要验证。

## 备选框架（按场景挑）

### ICE（轻量版，没 Reach 数据时用）

```
ICE Score = Impact × Confidence × Ease
```

适合早期阶段、没 reach 数据、需要快速排序。

### WSJF（SAFe 框架，跨团队多 epic 时用）

```
WSJF = Cost of Delay / Job Size
Cost of Delay = Business Value + Time Criticality + Risk Reduction / Opportunity
```

适合多 epic 跨团队竞争资源、季度规划、年度路线图。

### MoSCoW（产品阶段定义时用）

- **M**ust have：核心价值，没它产品不成立
- **S**hould have：重要但不致命
- **C**ould have：锦上添花
- **W**on't have（this time）：明确 kill

适合 MVP 范围定义、版本边界划定。

## 6 步标准流程

1. **列候选**：把所有要排序的项列清单（写下来，不在脑里）
2. **选框架**：默认 RICE。没 reach 数据 → ICE。跨 epic → WSJF。MVP 范围 → MoSCoW
3. **维度评分**：每个项每个维度写具体数字 / 等级，**不允许"高/中/低"模糊填**
4. **算分排序**：算出 RICE/ICE/WSJF 分数，降序排列。MoSCoW 直接归类
5. **审视 Confidence**：所有 Confidence < 80% 的项标"⚠️ 假设需验证"，列具体要验证什么
6. **二级决策**：分数前 30% 进 do-list；中段 30% 标"等条件"；后 30% 标 kill 或归档

## 小红线

- **不接受全 100% Confidence**：意味着没人在认真估
- **不接受 Reach = 1**：单用户级需求要么是 Tier A 战略合作（直接走例外通道），要么不该上 backlog
- **Effort 估错优于不估**：先填一个数后续调整 > 留空导致整个 RICE 算不出
- **Impact = 3 不超过 20%**："大量影响"是稀缺信号，不能稀释

## 模板（Markdown 表格）

```markdown
| 项目 | Reach | Impact | Confidence | Effort | RICE 分 | 假设需验证 |
|---|---|---|---|---|---|---|
| <项目 1> | 5000/月 | 2 | 80% | 2 | 4000 | - |
| <项目 2> | 1000/月 | 3 | 50% ⚠️ | 1 | 1500 | "用户真的会用"未验证 |
| <项目 3> | 10000/月 | 1 | 100% | 3 | 3333 | - |
```

排序后给：**top 3 do-list / 中段 hold-list / 底部 kill-list**。

## Anti-Rationalization

| 逃逸路径 | 为什么不行 |
|---|---|
| "凭直觉排个序就行了" | 直觉排序 = 隐藏的"我觉得"。强迫维度拆分会暴露被低估 / 高估的假设 |
| "Reach 没数据就跳过 RICE" | 没 reach 数据用 ICE。完全跳过评分 = 回到 gut-feel = 决策不可追溯 |
| "Confidence 全填 80%" | 80% 是默认偷懒值。必须按具体维度想：reach 数据可信度？impact 估算可信度？effort 估算可信度？三者同 80% 概率极低 |
| "Effort 估不准就不估" | 估不准也要估。估错可调整，不估整张表就废了 |
| "排出来分高的不是我想做的，那 RICE 是错的" | RICE 没错，是你想做的项假设没列清。回 step 5 把"我想做"的真实理由列出来——可能是战略 / 个人偏好 / 老板压力——这些是另外的输入维度，不该让 RICE 背锅 |
| "Impact 全打 3 反映这些都很重要" | Impact = 3 上限是 20% 候选项。全 3 = 没认真区分 = 评分失效 |
| "MoSCoW 比 RICE 简单先用 MoSCoW" | MoSCoW 是 MVP 范围工具不是优先级工具。Must have 之间还要 RICE 排，Could have 也要 RICE 评。框架场景不同 |

## 关联

- 评分完后下一步：do-list 项进 `story-splitting` 拆故事 → `pre-mortem` 失败推演
- 假设需验证项进 `gtm-ops:growth-engine` 设 A/B 验证
- 大型 epic 用 WSJF 后再往下拆 sprint → `product-management:sprint-planning`

## Status

v1.0 — 2026-05-08 product-thinking plugin v0.1.0 首发。