結論先講
Backlog 不是待辦清單，是策略工具。排序不是靠「誰喊最大聲」，而是靠框架和數據。這篇教你三種排序方法（RICE、MoSCoW、ICE），怎麼處理技術債，以及當老闆說「全部都很急」的時候怎麼應對。
為什麼 Backlog 管理很重要
一個沒管理的 Backlog 長這樣：
- 300 張 ticket，其中 200 張超過半年沒人看
- 沒有優先順序，或者全部標「高」
- 混雜著功能需求、bug 修復、技術債、個人心願
- 每次 Sprint Planning 花兩小時吵要做什麼
一個管理良好的 Backlog：
- 前 20 張 ticket 是精煉過、可以馬上開工的
- 有清楚的優先順序和排序依據
- 定期清理過期或不再需要的項目
- Sprint Planning 30 分鐘就能結束
RICE 框架
RICE 是 Intercom 發明的排序框架，適合產品團隊。
公式
RICE Score = (Reach × Impact × Confidence) / Effort
| 因子 | 定義 | 衡量方式 |
|---|---|---|
| Reach | 影響多少使用者 | 每季受影響的使用者數 |
| Impact | 對每個使用者的影響程度 | 3=大量 / 2=高 / 1=中 / 0.5=低 / 0.25=極低 |
| Confidence | 你對估算的信心 | 100%=高 / 80%=中 / 50%=低 |
| Effort | 需要多少人月 | 人月數 |
實戰範例：電商平台功能排序
| 功能 | Reach | Impact | Confidence | Effort | RICE Score |
|---|---|---|---|---|---|
| 結帳頁面優化（減少步驟） | 10000 | 3 | 80% | 2 | 12000 |
| 新增超商取貨 | 8000 | 2 | 100% | 3 | 5333 |
| 會員點數系統 | 5000 | 2 | 50% | 4 | 1250 |
| 後台報表重新設計 | 50 | 1 | 80% | 2 | 20 |
結帳頁面優化的 RICE Score 最高，因為它影響所有結帳使用者、衝擊大、團隊有信心能做好。後台報表雖然內部同事一直喊，但 Reach 太低，排序自然靠後。
RICE 的限制
- Impact 的評分很主觀
- 不適合緊急的 bug 修復（需要另外的處理流程）
- 比較適合「功能 vs 功能」，不適合「功能 vs 技術債」
MoSCoW 方法
MoSCoW 適合有明確 deadline 的專案（例如外包、產品上線）。
| 分類 | 定義 | 佔比建議 |
|---|---|---|
| Must have | 沒有就不能上線 | 60% |
| Should have | 很重要但不至於擋上線 | 20% |
| Could have | 有的話更好 | 15% |
| Won’t have | 這次不做（但記錄下來） | 5% |
實戰範例：電商 MVP
| 功能 | 分類 | 理由 |
|---|---|---|
| 商品瀏覽 | Must | 核心功能 |
| 購物車 | Must | 核心功能 |
| 信用卡付款 | Must | 至少要有一種付款方式 |
| 超商取貨 | Should | 重要但可以第二版 |
| 會員點數 | Could | 增值功能 |
| AI 推薦 | Won’t | 太複雜，第一版不做 |
MoSCoW 的關鍵
Won’t have 不是垃圾桶。 它是跟利害關係人的明確約定：「這個需求我們聽到了，但這次不做。」有了 Won’t have，你就有了說不的依據。
ICE 評分
ICE 比 RICE 簡單，適合快速決策。
公式
ICE Score = Impact × Confidence × Ease
| 因子 | 評分 |
|---|---|
| Impact | 1-10 |
| Confidence | 1-10 |
| Ease | 1-10（10 = 最容易做） |
範例
| 功能 | Impact | Confidence | Ease | ICE |
|---|---|---|---|---|
| 一鍵結帳 | 9 | 7 | 4 | 252 |
| 修復搜尋 bug | 6 | 9 | 8 | 432 |
| 新增願望清單 | 5 | 6 | 7 | 210 |
搜尋 bug 的 ICE 最高——影響雖然中等，但信心高、容易做。這就是「low-hanging fruit」（唾手可得的成果）。
什麼時候用 ICE vs RICE
- ICE：快速決策、團隊小、不需要跟外部對齊
- RICE：需要跟利害關係人溝通、需要數據支撐的場景
技術債 vs 功能：怎麼排
這是每個工程團隊都會碰到的難題。PM 想要新功能，工程師想還技術債。
技術債分類
| 類型 | 範例 | 緊急度 |
|---|---|---|
| 破窗型 | 程式碼到處複製貼上、沒有錯誤處理 | 中 |
| 地基型 | 架構不適合現有規模、資料庫 schema 混亂 | 高（越晚處理越貴） |
| 效能型 | 頁面載入慢、API 回應超時 | 看影響範圍 |
| 安全型 | 依賴套件有漏洞、密碼沒加密 | 最高 |
排序建議
- 安全型技術債：立刻處理，不需要排進 backlog
- 地基型技術債：當它開始拖慢新功能開發速度時處理
- 效能型技術債：當它影響使用者體驗時處理
- 破窗型技術債：分配 Sprint 容量的 15-20% 持續改善
跟 PM 溝通技術債的方法
不要說：「我們需要重構。」
要說：
「目前加一個付款方式需要 5 天，因為程式碼耦合度太高。如果我們花 2 週重構金流模組，之後加每個付款方式只需要 1 天。考慮到今年計畫要加三種付款方式，重構可以省下 12 天。」
用業務語言和數字說話，不要用技術術語。
當老闆說「全部都很急」
這句話翻譯成人話就是：「我不想做取捨。」
你的應對方式：
1. 強制排序法
「我理解這五個需求都很重要。但如果團隊只能做三個，你會選哪三個？如果只能做一個呢？」
強迫對方做排序，而不是讓你去猜。
2. 成本可視化
「這五個需求的總工時是 15 週。我們的團隊容量是每 Sprint 完成 3 週的工作量。如果全部都要做，需要五個 Sprint（2.5 個月）。」
讓他看到「全部都要」的代價。
3. 機會成本法
「如果我們先做 A 和 B，可以在下個月就上線帶來營收。如果五個一起做，全部都要等到三月才能上線。」
讓他看到「先做哪個」的差別。
4. 數據驅動
把 RICE 分數攤開來：
「根據 RICE 評分，A 的分數是 12000，E 的分數是 20。從投資報酬率來看，我建議先做 A、B、C。」
Backlog Grooming 實戰流程
Grooming（或叫 Refinement）是定期整理 Backlog 的會議。
建議頻率
每週一次，每次 1 小時。
參與者
PO + 2-3 名資深工程師（不需要全團隊）。
流程
| 步驟 | 時間 | 活動 |
|---|---|---|
| 1 | 10 分鐘 | 回顧上次 grooming 的 action items |
| 2 | 20 分鐘 | PO 介紹新的 stories，團隊問問題 |
| 3 | 15 分鐘 | 補充 Acceptance Criteria |
| 4 | 10 分鐘 | 粗估（T-shirt sizing） |
| 5 | 5 分鐘 | 排序和清理（刪除過期的 ticket） |
Grooming 的產出
- 前 2-3 個 Sprint 的 stories 已精煉、可開工
- 過期或不再需要的 ticket 已關閉
- 新發現的需求已記錄
Backlog 健康度檢查表
每個月花 15 分鐘做一次：
- Backlog 總數在可管理範圍（< 100 張活躍 ticket）
- 前 20 張 ticket 都有 AC 和估算
- 沒有超過 3 個月沒更新的 ticket（該關就關）
- 技術債至少佔 15-20% 的容量
- 排序依據有文件記錄（不是在某個人的腦袋裡）
- 利害關係人知道目前的排序（沒有驚喜）
FAQ
Q1：Backlog 有幾百張 ticket，怎麼清理？
先做一次大掃除：超過 6 個月沒更新的全部關掉。如果真的重要，以後會有人再開。然後設定規則：每個月自動標記 3 個月沒更新的 ticket，由 PO 決定關閉或保留。
Q2：RICE 的 Impact 怎麼評，感覺很主觀？
確實主觀，但你可以用歷史數據校準。例如：上次做了「改善搜尋」，Impact 估 3，實際上線後搜尋轉換率提升了 15%。記錄這些，慢慢建立團隊的共同標準。
Q3：PO 和工程師對優先順序有分歧怎麼辦？
正常。PO 看商業價值，工程師看技術風險和可行性。解法是：讓工程師提供技術觀點（「這個做法有技術債風險」），但最終排序權在 PO。如果工程師認為有嚴重技術風險，要求寫進 ticket 的風險欄位，讓決策有紀錄。
Q4：Bug 要排進 Backlog 嗎？
看嚴重度。P0（系統崩潰）和 P1（核心功能壞掉）不走 backlog，直接進行中。P2（功能有問題但有 workaround）排進 backlog。P3（UI 小問題）可以排，但老實說很多 P3 最後都會被關掉。
Q5：怎麼避免 backlog 變成許願池？
設定「入場門檻」：每個新 ticket 至少要有 (1) 使用者角色 (2) 問題描述 (3) 預期效益。沒有這三項的不准進 backlog。這會自然過濾掉那些「想到什麼就開一張」的雜訊。