為什麼要估算？

很多剛接觸敏捷的人會問：「敏捷不是強調快速回應變化嗎？那還需要估算嗎？」

事實上，估算並不是為了追求「精準到小數點」的時間預測，而是要幫助團隊、產品負責人與利害關係人，對未來的交付節奏有一個可依賴的方向感。

在敏捷開發的規劃中，估算扮演了三個重要角色：

1. 協助預測交付能力

   透過估算故事點數或工作量，團隊可以推算出自己在一個迭代（Iteration）內大概能處理多少工作。

   這種能力的衡量，不是要追求精準數字，而是幫助大家對工作量有合理的預期，避免「想做的」遠超過「能做的」。

   就像搬家時會先評估車子的載重量和傢俱的數量，不是要算到每公斤，而是避免一次搬太多導致塞不下或壓壞。

2. 支援發行計劃與優先順序調整

   當我們知道某個功能大約需要多少點數，就能更容易排定優先順序和發行節點。

   例如，如果兩個重要功能加起來超過團隊的迭代容量，就必須決定誰先做、誰延後，或是先拆成較小的版本。

3. 建立團隊共識與期望管理

   估算不是某個人拍腦袋決定，而是全體成員共同討論、評估技術難度與風險的過程。

   這不僅讓團隊對工作內容有共同理解，也能讓產品負責人或客戶理解交付的現實條件，減少「想當然爾」的誤會。

總結來說，估算的價值在於促進溝通與支持決策，而非追求數學上的精確度。缺乏估算的團隊，就像在濃霧中行車，雖然車子依然能前進，但方向感模糊、速度難以控制，自然也很難安全且準時地抵達目的地。

故事點數 vs. 時間預估：兩種不同的衡量方式

在敏捷團隊中，估算常見有兩種單位：故事點數（Story Points）和時間（小時／天）。雖然它們都是用來評估工作量，但背後的思考方式與用途並不相同。

1. 故事點數：相對衡量的單位

   其核心概念為比較工作彼此的相對大小，而不是直接計算花費時間。

   以故事點數預估的好處是避免糾結在「時間」的數字上，讓討論專注在工作本身的難度與不確定性，也能更容易在不同類型的工作之間做比較（例如前端改版 vs. 後端 API 開發）。

   如果配合團隊的速度（Velocity）使用，也能預測在下一個迭代大約能完成多少點數的工作。

2. 時間預估：直接衡量的單位

   直接預估工作需要的實際人時或人天。

   在與外部團隊或利害關係人溝通成本時（例如預算編列），或是特定短期活動需要精準時間安排（例如切換系統、資料遷移）的時候，使用時間預估來溝通會比較便利快速。

   但時間預估容易被視為「承諾」，導致壓力與過度承諾。若缺乏對不確定性的彈性處理，便容易失真和引發不良反應。

迭代內的計劃與追蹤，建議用故事點數，保持專注在相對難度與團隊速度。若是對外報告或資源規劃，為了方便說明，可以轉換成時間，但要明確表達這個時間僅是推估，而非保證。

故事點數與時間並不是互斥的，可以先用故事點數建立團隊內的共識，再用團隊歷史數據換算成時間，協助外部溝通。這樣既保留敏捷的彈性，也能回應管理層對預算與時程的需求。

常用的故事點數估算方法

估算故事點數的目標，不是追求「最精確的數字」，而是快速建立團隊共識。以下介紹三種在敏捷團隊中常見且實用的方法：

規劃撲克（Planning Poker）

• 做法：
  1. 每位成員手上有一組帶有數字的卡片（數字常用費氏數列：1、2、3、5、8、13…）。
  2. 產品負責人或需求方先解釋一則使用者故事。
  3. 團隊討論確認需求後，每人同時亮出自己對該故事的估算卡片。
  4. 若估算差異大，請數字最大和最小兩端的人解釋理由，再重新估算。
• 優點：
  • 團隊全員參與，能快速對需求達成共同理解。
  • 有助於發現需求的模糊點或隱藏的風險。
• 缺點：
  • 多個故事時可能耗時較長，尤其在討論差異的部分。

尺寸分類法（T-shirt Size）

• 做法：
  1. 先定義 S、M、L、XL（有時增加 XS、XXL）對應的相對工作量。
  2. 按照直覺把故事分配到不同尺寸分類。
  3. 如有爭議，先討論需求或技術細節再調整。
• 優點：
  • 速度快，適合在需求量很大、還不需要精細數字的早期階段使用。
  • 方便對尚未完全確定細節的故事做粗略分類。
• 缺點：
  • 精度低，如需要後續仍可能得轉換成故事點數或更細的估算。

理想工時/理想天數（Ideal Days/Hours）

• 做法：
  • 直接估算完成故事所需的時間（理想時間，不計入干擾）。
• 優點：
  • 容易讓新手理解，無需轉換估算單元概念。
• 缺點：
  • 容易與實際工作天數時間混淆，造成誤解。

估算的限制與迷思

在敏捷團隊中，估算的目的在於協助規劃與溝通，但若方法或心態錯誤，就可能讓估算變成壓力來源，甚至失去參考價值。以下是幾個常見陷阱：

1. 過度精確

   花大量時間討論，只為了把故事點數從「5」改成「3」或「8」。精確不等於準確，這樣反而是浪費時間。可以設定估算時間上限（例如每則故事不超過 5 分鐘），讓團隊追求共識而非絕對數字。

2. 低估造成交付壓力

   為了顯得「效率高」，故意報低點數，導致團隊過度承諾，後續疲於應付。估算是為了團隊共識，而不是用來做績效評比，因此估算時需考慮風險與未知因素，而不是追求「表面上的數字」。

3. 忽略未知與風險

   估算時只看當下已知的工作量，沒有將需求模糊、技術不熟、外部依賴等不確定性納入。

4. 將故事點數等同於時間承諾

   例如把 5「點」直接翻譯成 5「天」，導致點數失去相對衡量的彈性。應保持故事點數的相對性，只在需要對外溝通時再轉換為時間，並說明時間只是推估。

5. 忽視歷史數據

   每次估算都「憑感覺」，導致規劃失準且波動大。需要定期檢視團隊的速度與過往估算偏差，逐步建立團隊的估算基準。

估算的重點在於「理解需求並對齊期望」，而不是用來「精算交付日期」。如果討論陷入僵局，可以先透過尺寸分類法進行粗略估算，等到迭代計劃會議時再做更精細的拆解。

同時，也建議在每次回顧會議中檢視估算的準確度，逐步調整並建立團隊對故事點數的共同認知。

估算與發行規劃的連動

故事點數本身並不會告訴我們「什麼時候能交付」，但當它與團隊的速度結合時，就能成為發行規劃的關鍵依據。

什麼是團隊速度？

所謂「團隊速度」，指的是團隊在一個迭代內平均能完成的故事點數總和。計算方式相當單純，就是取過去各次迭代中已完成的故事點數，然後計算平均值。

但要特別注意，只有真正符合「完成的定義（Definition of Done, DoD）」的故事才能納入計算，進行中或半成品一律不算在內。

團隊的速度並不是績效分數，而是團隊容量的觀察數據。它反映的是「團隊在當前情境下的穩定交付能力」。

從估算到發行計劃

透過以下四步，我們可以利用團隊速度來估算發行日期：

1. 先用故事點數來估算下一次發行所需待辦項目（Backlog）的相對大小。
2. 將屬於該發行範圍的功能點數加總，得到所需的故事總點數。
3. 用這個總點數除以團隊的速度，就能推算出大約需要多少個迭代。
4. 再依據迭代數量與迭代長度，推算出預計的發行日期。

例如一個簡單的範例：

假設待辦項目的功能總點數為 120 點，而團隊的平均速度是每個迭代 20 點，則需要的迭代數為：120 ÷ 20 = 6 個迭代。若每個迭代長度為兩週，便可推算大約在三個月後即可完成並發行版本。

彈性調整的策略

一個新團隊在前幾個迭代的速度波動會很大，應該等數據穩定後再用來做發行預測比較可靠。

當需求有變動或是團隊的速度變快或變慢時，需要重新計算總點數與發行節點，即時更新預測，及早通知利害關係人。

若想提早發行日期，應該使用最小商量增量（MBI）或優先順序調整發行的範圍，而非一味壓縮時程。

持續調整估算準確度

估算能力並不是一次就能定型的技能，它需要隨著團隊經驗、需求特性與外部環境的變化，不斷調整與優化。以下是幾個讓估算流程持續進化的實務做法：

1. 在回顧會議檢視估算偏差

   在迭代回顧會議時，挑出幾個與估算偏差最大的故事，討論是什麼原因造成的（需求變動？技術挑戰？外部依賴？）。

   找出可改善的流程並於下一輪時進行改善實驗，例如需求澄清不足、技術方案過於樂觀、依賴風險評估不足。

   要提醒的是：檢討的標的是流程與假設，不是個人能力，避免讓檢討變成批鬥大會。

2. 建立團隊的估算基準

   挑出幾個團隊已完成、共識度高的故事，作為不同點數的「標準範例」。除了避免不同人對同一點數有不同理解也能讓新成員能快速對點數有感覺。

3. 隨著學習與情境變化調整方法

   團隊初期可用簡單的尺寸分類法進行粗估，等共識建立後改用規劃撲克做細估。方法沒有固定標準，應根據團隊成熟度與當下情境靈活調整。

估算不是一次性的「預測動作」，而是一種需要持續練習、回顧與調整的團隊能力。當團隊能在穩定的估算基礎上靈活應對變化，就能讓規劃更可靠、溝通更順暢、交付更有把握。

估算的真正價值是促進溝通、建立共識、支持決策

在敏捷開發中，估算的真正價值不在於精準預測交付日期，而在於促進溝通、建立共識、支持決策。透過故事點數這種相對衡量方式，團隊能更專注於工作本身的複雜度、風險與未知，而不是被時間壓得喘不過氣。

當估算與速度結合時，便能為發行規劃提供可靠的依據。持續檢視估算偏差、建立參考故事的基準、並依情境調整方法，則能讓團隊的估算能力愈加穩定，愈貼近現實。

敏捷中的估算，就像航海時的羅盤，雖不能精確指出每一分每一秒的位置，但能讓團隊在瞬息萬變的海面上，始終掌握正確的方向。