Story point 與 Lead time
用估算談風險，用分位數談交期
事實、感覺與承諾
在「後事實」時代，情緒與信念常輾過證據。團隊對每個 Item 在對話的時候也常如此：「這張看起來很大、很難」的感覺，比「實際要等多久」的證據更大聲。
我會認為大家把兩種話分開：
- 用 story point 談理解與風險（感覺的共識）
- 用 lead time 談交期與流程（可重現的觀察）
當我們把感覺與證據擺回各自的位置，承諾就不再是辯術，而是概率聲明：「這類工作，我們有 85% 在 X 天內完成。」
• story point 是什麼層次？
觀點值（團隊對複雜度與風險的共同評估）。它是有用的專業判斷，但不是時間事實，不可直接換算天數。
• lead time 是什麼層次？
觀察事實（從承諾到完成的實際經過時間）。在起訖點定義一致、可稽核的前提下，它是可重現的度量。由於常見右長尾，通常不看平均值，而看 85% 分位數落在幾天，拿來做對外承諾最穩。
story point 屬於「我們怎麼看它」
lead time 屬於「它實際發生了什麼」
它們在量什麼
- story point：我們對這件工作的主觀大小感（包含複雜度與風險程度）。重點是幫我們討論、切小、看風險。
- lead time：這件工作從「答應要做」到「真的完成可交付」的實際經過時間。重點是對外說「多久會好」，以及看流程哪裡在讓人等待。
story point 看工作本體；lead time 看系統流程。
什麼時候用、什麼時候別用
story point — — 適用
- 開工前判斷要不要切小、哪裡有未知。
- 同一團隊內粗估這個 Sprint 大約能放多少工作。
story point — — 不適用
- 別用來回答「什麼時候好」。
- 別拿來做績效比較；一比較就會膨脹，討論會走鐘。
lead time — — 適用
- 對外承諾「大多數工作多久完成」。
- 找瓶頸：等待審核、等待外部、等待環境等。
- 排程與預測：估一批工作大概什麼時候做完。
lead time — — 不適用
- 別用它判斷工作「難不難」；時間長可能只是在等。
- 起訖定義不一致就不要比較；請先對齊「從哪一刻開始算，到哪一刻算完成」。
重要補充：通常不看平均值，而是看 85% 分位數 的 lead time
- lead time 常常是右長尾（偶爾會拖很久），平均值很容易被極端值拉走，對承諾沒有保證。
- 我們在現場一律用分位數說人話：「我們不看平均值，而是看 85% 的 lead time 落在幾天。」
- 通常會這樣對話：「這類工作，我們有 85% 在 8 個工作天內完成。」這比「平均 6 天」更可靠、更能對外承諾。
軟體開發的例子
例子一：同樣的複雜度與風險，等待卻差很多
- 後端新增「報表匯出」功能，兩個團隊都估成 story point = 5（意思是：中度複雜、存在幾個可識別的風險，但不至於高風險）。
- 團隊 A 的 lead time 是 3 天；團隊 B 的 lead time 是 10 天。
- 差異點：團隊 B 碰到共用測試環境排隊與架構審查檔期，等待時間大幅拉長。
→ 結論：story point 只在說「這件事的複雜度與風險評估大致相當」，不代表要做幾天；lead time 則揭露「系統的等待與流動是否順暢」。對外承諾請報「這類功能的 85% 分位數 lead time」。
例子二：複雜度與風險不同，但交付時間相近
- A 任務：切換一個設定開關，評為 story point = 2（低複雜、低風險、變更面小）。
- B 任務：資料庫結構調整與回填，評為 story point = 8（高複雜、高風險，需要回滾方案與更完整測試）。
- 兩個任務的 lead time 都落在約 5 天左右。
- 為什麼？兩者都卡在同一班發版列車與固定的變更審核時窗，主要時間花在「等時窗、等列車」。
→ 結論：lead time 告訴你「系統性約束讓大家一起等車」；story point 的用途是暴露不確定性、安排試探性工作（spike）、決定測試深度與風險緩解，不是用來換算幾天。因此在排程與承諾上，看平均值沒有意義，應以 85% 分位數的 lead time 為依據；在設計與切分上，則用 story point 來引導複雜度與風險對話。
生活裡的例子
例子三：點披薩
- 你說「來個大披薩」＝對大小的主觀選擇，像 story point。
- 從下單到拿到手要多久，取決於店裡排隊、外送塞車，這是 lead time。
- 如果你要跟朋友說幾點開動，別說「平均 25 分鐘」，要說「我們有 85% 的情況在 40 分鐘內拿到。」
例子四：搬家
- 估計要打包的箱數與雜亂程度，像 story point；
- 從開始打包到全部搬進新家，中間卡在電梯排隊、貨車排隊，這段就是 lead time。
- 對家人承諾時間時，用「我們 85% 的情況在下午三點前搬完」，比「平均兩小時」更穩。
在實務可以這樣落地
- 先對齊 lead time 的起訖點
例如：「從拉進承諾欄位，到達到可交付的完成定義」。團隊一致最重要。 - 對外用分位數說人話（避免平均值）
直接說：「我們不看平均值，而是用 85% 分位數的 lead time 做承諾，目前是 8 個工作天。」 - 把等待視覺化
在看板上標記等待的時段：等待審核、等待外部、等待環境。讓瓶頸無所遁形。 - 降低同時間在做的事情數量
同時做越多，整體越慢。先少開幾張票，通常 lead time 會先明顯下降。 - 保留 story point 的價值
把它用在切分、風險對話與共識，不要把它變成比快的遊戲。
總之～
把兩個數據各就各位：story point 讓我們在開工前把事情看清楚；lead time（用 85% 分位數）讓我們對外說話有根據、對內改善有抓手。
當團隊的對話清楚了，交付會更穩，彼此的信任也會更穩。
常見困惑
1. 常見問題：lead time 不看 story 大小嗎？
短答：對，lead time 主要不看 story 大小。lead time 在量「一件工作穿越我們系統、從答應到完成的實際時間」，這裡面等待、排隊、移交、審核、環境準備往往比「工作本身有多大」更影響總時間。
補充：story 大小會影響「實作花的手工時間」，但整體等候常常主宰結果。所以用 lead time 做對外預測時，通常不需要 story point；如果團隊故事大小差異真的很大，可以用下面兩種做法更精準：
- 把常見工作分成幾種型態或粗大小（例如：修錯誤、小功能、一般功能），各自觀察 85% 的 lead time。
- 切成薄的垂直切片，讓每張故事的大小更接近，lead time 的分布也會更穩定。
軟體例子
- 兩張故事：一張是介面文字微調（小），一張是資料庫調整（大）。結果兩張的 lead time 都是五天。為什麼？因為兩張都卡同一班發版列車，等車花掉四天；實作只是一小段。
- 反過來，有時一張「看起來大」的故事 三天就完成，因為它走的是專屬通道、沒有排隊。
→ 所以 lead time 反映的是系統在讓人等待，不是故事大或小。
生活例子
- 去醫院看診：你的病情大小不同，但你等診的時間，大多被掛號順序與現場壅塞決定。小毛病也可能等很久；大毛病若走綠色通道反而更快。
→ lead time 跟排隊系統有關，不是只看「事情本身大小」。
2. 常見問題：切小 story point 可以幫助預測嗎？
短答：間接有幫助，但關鍵不在點數，而在批量與等待。把故事切小、切成薄的垂直切片，通常會：
- 降低變異：每張故事走的路徑更相似，lead time 的分布比較穩，85% 更容易掌握。
- 增加可觀察的樣本數：更快累積歷史資料，預測區間更窄。
- 減少半成品數量：小批量流動更順，等待縮短、lead time 下降。
但也要避免過度碎片化：如果切成很多彼此依賴、還要多次移交的小碎片，反而增加交接與管理成本，lead time 可能並不會縮短。好的切法是「垂直切片」：每一片都能獨立完成、可驗證、可交付，不是把同一件事切成前端一張、後端一張、測試再一張。
軟體例子
- 原本有一個 13 點的大功能，歷史 lead time 的八十五百分位在二十天，而且範圍很分散。把它切成五張「可以各自上線」的垂直切片（每張二到三點），上線路徑一致、等待相近，結果每張八十五百分位落在六到八天。
- 用這樣的歷史資料做預測時，一批十張故事的完成區間，會比原本「一大坨」的預測更短、更可承諾。
生活例子
- 烘焙：一大盤厚蛋糕常常中心不熟、時間難抓；改成多片薄蛋糕或餅乾，每片的熟成時間更接近，整體完成時間更可預期。
- 搬家：一次塞滿一輛大卡車，會被電梯排隊、交通壅塞放大不確定；改為多次小趟、各自時間短，每一趟的完成時間更穩定，整體安排可預測。
落地建議
- 把「可接受的故事大小」界線說清楚，例如：希望大多數故事的八十五百分位 lead time 在 3 到 8 個工作天。
- 每週看一次最新的 lead time 分布，用它更新對外的說法。
- 發現某些故事類型總是拖很久，就為那一類單獨建立八十五百分位的目標，或改變流動策略（例如優先順序或專屬通道）。
總結
- lead time 用來對外預測與找瓶頸，通常不看 story 大小；
- 切小若是垂直切片，能讓 lead time 的八十五百分位更穩、更短，預測自然更準。
