估算（Estimation）與速率（Velocity）是 Scrum 規劃的兩大基石。本章說明如何估算產品待辦項目的大小、如何衡量團隊速率，以及兩者如何共同推導出開發所需的時程與成本。

概觀#

在規劃與管理產品開發時，我們需要回答三個關鍵問題：

1. 能完成多少功能？
2. 何時能完成？
3. 要花多少成本？

Scrum 的做法是：先估算要建造的東西有多大（size），再衡量團隊完成工作的速率（velocity），最後透過公式推導出時程：

估算大小 / 衡量速率 = 所需 Sprint 數

例如：Release 1 的 PBI 總大小為 200 點，團隊平均每個 Sprint 完成 20 點，則需要 10 個 Sprint 來完成 Release 1。

什麼時候估算什麼#

在產品開發的不同階段，我們需要在不同粒度層級進行估算，使用不同的單位：

Portfolio Backlog Item 估算#

Portfolio Backlog 包含所有需要建造的產品或專案的優先順序清單。由於此階段通常沒有完整的需求細節，多使用粗略的相對大小估算，例如 T-shirt Size。

Product Backlog 估算#

當 PBI 的優先順序提升並經過梳理（Grooming）增加更多細節後，團隊會使用 Story Points 或 Ideal Days 進行數字化的大小估算。

有些 Scrum 實踐者認為 PBI 大小估算並非必要——當團隊夠成熟，能將 PBI 拆到大小相近時，直接計算數量即可。但作者仍傾向估算 PBI，因為：

• 並非所有 PBI 會在同一時間達到相同大小
• 團隊需要時間培養拆解技能
• 為了達到相同大小而在不自然的位置拆分故事並不理想
• 估算對話中的學習是最大的價值——要求人們對某個東西給出數字，能立即暴露分歧並迫使假設浮出水面

Task 估算#

Sprint Backlog 中的 Task 使用 Ideal Hours（也稱為 effort-hours、man-hours、person-hours）進行估算。例如 UI 任務估計 5 effort-hours，不代表 5 小時後完成，而是需要消耗團隊 5 小時的工作量。

PBI 估算核心概念#

以團隊為單位估算（Estimate as a Team）#

Scrum 的原則是：由實際執行工作的人來集體提供估算。

• 開發團隊：負責估算，從各自的專業角度共同決定大小
• Product Owner：描述 PBI 並回答澄清問題，但不提供估算，也不應引導團隊朝向特定數字
• ScrumMaster：協助教練和促進估算活動

估算不是承諾（Estimates Are Not Commitments）#

如果告訴團隊「你的獎金取決於估算是否正確」，每個人都會給出遠大於實際的估算。估算應該是對事物大小的真實衡量，不應因為外部壓力而被人為膨脹。

將估算視為承諾會導致數字被反覆操弄——團隊膨脹估算、管理層壓縮估算——最終沒有人真正理解這些數字的含義。

重視準確度而非精確度（Accuracy over Precision）#

• 過度精確的估算（如 10,275 人時或 $132,865.87）是浪費
• 產生估算的過程浪費時間，且會造成虛假的確定感，導致錯誤的商業決策
• 應投入剛好足夠的精力來獲得大致正確（roughly right）的估算
• 存在一個報酬遞減點：超過該點，額外的努力不會帶來對應的準確度提升

使用相對大小估算（Relative Size Estimation）#

人類天生更擅長判斷相對大小而非絕對大小。

作者在課堂上做的實驗：請 30 人估算到對面牆的「絕對距離」，得到 27 個不同答案；再請他們估算投影機在自己和對面牆之間的「相對位置」，29 人都說「大約一半」。結論：估算技巧應建立在人們擅長的事情上（相對估算），而非不擅長的事情上（絕對估算）。

PBI 估算單位#

兩種最常見的 PBI 估算單位是 Story Points 和 Ideal Days。作者的經驗中約 70% 的組織使用 Story Points，30% 使用 Ideal Days。

Story Points#

Story Points 衡量 PBI 的整體大小或量級，綜合考量以下因素：

• 複雜度：例如複雜的商業演算法，最終產出不大但開發工作量大
• 物理大小：例如更新 60,000 個儲存格的試算表，不複雜但工作量龐大

Story Points 讓我們能做出比較性的判斷，例如：「如果建立工單的故事是 2 點，那搜尋工單的故事就是 8 點。」由於 Story Points 最終用於計算時程，它必須反映開發團隊視角的工作量。

Ideal Days#

Ideal Days 代表完成一個故事所需的 effort-days（人天數）。就像美式足球理論上 4 節各 15 分鐘（共 1 ideal hour），但實際比賽要 3 到 3.5 小時。

Ideal Days 的主要風險在於誤解。「這個 PBI 要 2 天」很容易被誤認為 2 個日曆天，而非 2 個理想工作天。如果組織內容易產生這種誤解，建議使用 Story Points。

Planning Poker#

Planning Poker 由 James Grenning 首先描述、Mike Cohn 推廣，是一種用於估算 PBI 大小的共識技術。

其核心概念包括：

• 共識導向（Consensus-based）
• 專家意見（Expert opinion）
• 深入討論（Intense discussion）
• 相對大小（Relative sizing）
• 準確分組/分箱（Accurate grouping/binning）
• 利用估算歷史（Leverage estimating history）

估算尺度#

團隊需要選定一組數字尺度。常用的有：

• 修改版 Fibonacci 數列（Mike Cohn 提出）：1, 2, 3, 5, 8, 13, 20, 40, 100
• 2 的冪次：1, 2, 4, 8, 16, 32, …

這種尺度的設計意圖是在小端提供較多選擇（需要較精確的區分），在大端提供較少、間距較大的選擇（避免過度精確）。就像郵局分揀包裹，每個包裹放入最匹配的箱子，箱中的包裹大小不會完全一樣，但屬於同一量級。

如何進行#

Planning Poker 的流程：

1. Product Owner 選取一個 PBI 並向團隊說明
2. 開發團隊成員討論並向 Product Owner 提出澄清問題
3. 每位估算者私下選取一張卡片代表自己的估算
4. 所有私下估算同時亮牌
5. 如果所有人選擇相同，即達成共識，該數字成為估算值
6. 如果不同，請最高和最低估算者解釋理由，團隊進行聚焦討論
7. 回到步驟 3 重複，直到達成共識

常見的特殊卡片含義：

Planning Poker 的最大價值不只是產生估算數字，而是討論過程中團隊對 PBI 的深入理解。要求人們給出數字，能迅速暴露假設與分歧。通常 2 到 3 輪投票即可達成共識。

flowchart TD
    A[PO 選取 PBI 並向團隊說明] --> B[團隊討論與提出澄清問題]
    B --> C[各成員私下選取一張卡片]
    C --> D[所有人同時亮牌]
    D --> E{結果一致?}
    E -->|是| F[達成共識，確定估算值]
    E -->|否| G[最高與最低估算者\n解釋理由]
    G --> H[團隊進行聚焦討論]
    H --> C

什麼是 Velocity？#

Velocity（速率） 是團隊每個 Sprint 完成的工作量，計算方式為加總該 Sprint 中所有完成的 PBI 的大小估算。

• PBI 要麼完成（done），要麼沒完成——部分完成的項目不計入 Velocity
• Velocity 衡量的是產出（output，交付了多大的東西），而非成果（outcome，交付了多少價值）

Velocity 有兩個重要用途：

1. 規劃工具：Release Planning 中用來計算完成 Release 所需的 Sprint 數；Sprint Planning 中作為團隊承諾工作量的參考
2. 診斷指標：團隊可透過觀察自身 Velocity 的變化，評估特定流程變更對客戶價值交付的影響

計算 Velocity 範圍#

Velocity 以範圍（range）表達最為有用，例如「團隊通常每個 Sprint 能完成 25 到 30 點」。

以 Release 1 大小為 200 點為例：

• 以較高速率 20 點/Sprint 計算：需要 10 個 Sprint
• 以較低速率 17 點/Sprint 計算：需要 12 個 Sprint
• 答案：Release 1 需要 10 到 12 個 Sprint 完成

使用範圍能準確地傳達不確定性，比單一數字更實際。可透過歷史 Velocity 數據，以高低平均值或信賴區間等簡單統計方法來計算這兩個數字。

預測 Velocity（Forecasting Velocity）#

當新團隊沒有歷史數據時，需要預測 Velocity：

• 讓團隊進行一次 Sprint Planning，決定能承諾哪些 PBI，加總其大小作為預測值
• 為了得到範圍，可以讓團隊規劃兩個 Sprint，使用兩次不同的估算值作為高低值
• 一旦團隊完成第一個 Sprint 有了實際 Velocity，就應捨棄預測值，改用實際值

影響 Velocity 的因素#

團隊的 Velocity 不會無限上升。一個積極改善自身、遵循健全 Definition of Done 且控制技術債務的團隊，Velocity 會上升到某個程度後趨於穩定（plateau）。

達到穩定後，可透過以下方式嘗試突破到下一個平台：

• 引進新工具
• 增加培訓
• 策略性地調整團隊組成

這些變更通常會先造成 Velocity 的短期下降，然後才會提升到新的平台。而隨意地將人員調入調出團隊，很可能只會導致 Velocity 持續下降。

加班的影響#

長時間加班的效果通常是：

1. 初期 Velocity 短暫上升
2. 隨後 Velocity 急劇下降，品質同步惡化
3. 加班結束後，團隊需要恢復時間才能回到基準 Velocity
4. 恢復期間的 Velocity 損失（低谷）往往大於加班期間的 Velocity 增益（高峰）

大量加班可能帶來短期利益，但長期後果往往遠超短期收益。

誤用 Velocity#

Velocity 應作為規劃工具和團隊自我診斷指標，不應作為績效衡量指標來評判團隊生產力。

誤用的典型場景：

• 跨團隊比較 Velocity：不同團隊的估算基準不同，Team A 對某 PBI 估 5 點、Team B 估 50 點，直接比較 Velocity 毫無意義
• 以最高 Velocity 發獎金：團隊會進行 Point Inflation（點數膨脹）——把原本估 5 的項目改估 500
• 更危險的情況：團隊為了追求更高 Velocity 而偷工減料，導致技術債務不斷累積

Velocity 的正確用法是協助準確規劃，以及幫助團隊內部自我改善。任何其他用途都可能促進錯誤的行為。

小結#

• 估算發生在三個層級：Portfolio（T-shirt Size）、Product Backlog（Story Points / Ideal Days）、Sprint Tasks（Ideal Hours）
• PBI 估算的四大核心概念：團隊估算、估算非承諾、重準確度輕精確度、使用相對大小
• Planning Poker 是最常見的 PBI 估算技術，透過共識、深入討論和相對大小分箱來產生估算
• Velocity 是每個 Sprint 完成的工作量，以範圍表達最準確
• 新團隊可透過模擬 Sprint Planning 來預測 Velocity，一旦有實際數據就應替換預測值
• Velocity 不應被用作跨團隊的績效比較指標，否則會引發點數膨脹或偷工減料等問題