User Story 拆不動？用 SPIDR + INVEST 建立團隊共用的拆解框架

我第一次教團隊拆 User Story 時，其實自己也沒搞懂 Negotiable。

現在回想起來，覺得自己也蠻厚臉皮的。我第一次在公司教團隊拆 User Story 的時候，自己根本也還搞不太清楚 INVEST 裡面的 Negotiable 到底是在 negotiate 什麼。

我以為自己懂了，就照著上課內容講一遍，再加上當時粗淺的認知——團隊聽完很禮貌地點頭，然後……就沒有然後了。

後來我帶團隊跑了幾輪 Refinement，採用「實例化需求」之後，在討論 Gherkin 的過程中我觀察到一件事：

討論常常變得很發散
時間很難收斂在預定範圍內

當時我還不太理解，後來才發現其中一個關鍵影響因素是：User Story 的拆解根本沒有做好。

團隊知道要拆小，但不知道怎麼下刀

我在指導某個團隊 Leader 時問他：

「這個『發送免費券』的 User Story 規模很大，規則十幾條，Scenario 快三十個，你打算怎麼在一個 Sprint 交付？」

他回我：

「喔，這沒辦法，只能延長到下個 Sprint 再交付吧。」

那一刻我突然懂了——團隊不是不知道 Story 要拆小，是根本不知道該怎麼動手。

帶的團隊多了，我發現拆不動 Story 的狀況就那幾種

1. 有拆，但其實是切成前後端任務

看起來卡片變多，但每一張都不能獨立交付使用者感受得到的價值。結果就是：

Sprint Review 只能 demo 半成品
或乾脆延到下個 Sprint 再 demo

2. Story 還很模糊，覺得差不多就開工

每個人腦中想像都不一樣。做到第三天才冒出一堆當初沒聊到的情境，Sprint 後半段整組人在：

補洞
補規則
補測試
補例外

3. 怕拆太細被覺得在「灌點數」，乾脆包大包帶進 Sprint

結果裡面藏著三四個沒人預期的邊界條件：

QA 測不完
時程炸開
客戶好一點：往後延一個 Sprint
客戶兇一點：整組加班收拾

4. 知道要拆小，但沒有穩定切法

每次全憑直覺，品質忽好忽壞：

資深的人在 → 拆得不錯
資深的人不在 → 打回原形

這些我自己全都經歷過，包括當年那個「以為自己懂了就去教人」的階段。

真正改善，是把兩個工具搭在一起用：SPIDR + INVEST

SPIDR：刀法，解決「我知道很大，但不知道從哪裡切」

SPIDR 給你 5 個切入角度：

Spike
Paths
Interfaces
Data
Rules

白話就是：解決「我知道這張太大，但不知道從哪裡下刀」這件事。

回到「發送免費券」這張 Story，用 Paths 展開，你會發現其實是完全不同的使用路徑：

首次註冊發券
滿額門檻發券
手動指定對象發券

這三個本質就應該拆開。

再用 Rules 去看：

每人限領一次
過期自動失效
與其他優惠是否併用

每一條背後的判斷邏輯、例外處理都不同——硬塞在同一張 Story 裡，Scenario 當然寫到快二十個，Refinement 時間也當然收不住。

INVEST：品管，解決「我拆完了，但拆得好不好？」

拆完之後，怎麼知道拆得好不好？這就是 INVEST 的價值。

Bill Wake 提出的 6 個檢驗原則，我現在更習慣把它當 User Story 的品檢單。每拆出一張就問自己（現在很輕鬆，可以靠 AI 做自動檢測）：

能不能獨立交付？
有沒有明確的使用者價值？
團隊估不估得出大小？
一個 Sprint 做不做得完？
測試案例寫不寫得出來？

只要任何一項答案是模糊的，通常就代表：還沒拆到位。

說回 Negotiable：我當初搞不懂的 N，到底在 negotiate 什麼？

現在回頭看，Negotiable 要講的是：Story 的細節應該保留協商空間，不要在 Refinement 階段就把實作方式寫死。

這件事我是踩了幾次坑之後才真的體會。光上課很難真正悟到。

結論：SPIDR 是刀法，INVEST 是品管

SPIDR 告訴你從哪裡切
INVEST 告訴你切得好不好

搭在一起用，Story 拆解就不再只能靠直覺碰運氣。

這幾年帶團隊，我越來越覺得——Story 拆不好，多半不是技術能力的問題，是缺一個團隊能共用的思考框架。

與其每次 Sprint Review 費力解釋為什麼沒做完，不如在 Refinement 多留 30 分鐘：

把 Story 拆清楚
把邊界條件講仔細

那三十分鐘省下來的，是整個 Sprint 的混亂跟返工。