「這個故事要估算幾點？」——對標準CRUD功能來說是個簡單的問題。但對AI功能而言，答案通常是「要看情況」，而這不是利害關係人想聽到的答案。
1. 為什麼AI故事更難估算？
AI工作有3個一般功能所沒有的不確定性來源：
| 不確定性來源 | 範例 | 影響 |
|---|---|---|
| 資料準備程度 | 資料管道尚未就緒 | 阻擋整個故事 |
| 模型效能 | 精確度能達到門檻嗎？ | 需要更多迭代 |
| 實驗分支 | 方法A失敗，需要重做方法B | 衝刺範疇改變 |
2. AI專案中的故事類型
區分3種故事類型以進行正確估算：
類型1：標準實作故事
功能定義明確，AI角色已設計好：
「作為客服人員，我希望在審查UI中看到AI建議
[UI已設計，API規格已有]」
→ 用規劃撲克正常估算
類型2：探針故事（研究故事）
方法不明，需要先調查：
「探針：評估3個嵌入模型用於客戶查詢分類。
時間盒：2天。輸出：建議文件。」
→ 不估算故事點數——固定時間盒
→ 探針的輸出 = 估算實作故事的輸入
類型3：實驗故事
需要執行實驗，結果不確定：
「實驗：測試GPT-4o-mini與Claude Haiku用於票務分類。
成功標準：任一模型達到87%的精確度。
時間盒：3天。如果兩者都未通過 → 向團隊升級。」
→ 時間盒＋成功標準，而非故事點數
3. 針對AI故事調整的規劃撲克
3.1 在估算中加入「不確定性維度」
傳統規劃撲克：1個數字（工作量）
AI調整版：2個數字（工作量 × 信心程度）
估算格式：[點數] / [信心程度：H/M/L]
範例：
- 開發者1：「8 / M」——8點但信心程度中等
- 開發者2：「13 / L」——13點信心程度低（許多未知因素）
- BA：「5 / H」——5點，信心程度高（需求明確）
當出現較大差異時 → 重新估算前先討論不確定性的來源。
3.2 不確定性分解討論
當信心程度低時，詢問團隊：
1. 「這個故事的哪個部分我們尚不清楚？」
2. 「我們需要解決哪些未知因素才能估算？」
3. 「我們需要探針，還是可以帶著緩衝來估算？」
4. 三點估算（PERT）
當不確定性高但不想要探針時，使用三點估算：
O = 樂觀（一切順利）
M = 最可能（正常條件）
P = 悲觀（出現問題）
E（期望值）= (O + 4M + P) / 6
範例：AI模型整合故事
O = 3天（API如文件所述運作）
M = 5天（1輪除錯）
P = 10天（API有錯誤，需要解決方案）
E = (3 + 4×5 + 10) / 6 = (3 + 20 + 10) / 6 = 5.5天
向利害關係人報告：「預期5到6天，視API穩定性，範圍為3到10天」
5. 向利害關係人溝通不確定性
原則：承諾範圍，而非精確點
避免：
「這個功能在第3個衝刺完成」（沒有根據）
應該說：
「這個功能有3個部分：
1. UI實作：信心程度高，第3個衝刺 ✅
2. API整合：信心程度中等，第3到4個衝刺
3. 模型精確度驗證：信心程度低——需要第3個衝刺的探針，
探針後重新估算」
不確定性溝通模板
## 功能估算：[功能名稱]
### 有信心的範疇（承諾）
- [元件1]：X點——需求明確 ✅
- [元件2]：Y點——已驗證的技術 ✅
### 不確定的範疇（指示性）
- [元件3]：~Z點——待資料驗證
- [元件4]：需要先進行探針（時間盒2天）
### 相依性 / 阻擋因素
- [ ] 需要[團隊]的資料管道在[日期]前準備好
- [ ] [利害關係人]確認模型門檻
### 建議方法
第N個衝刺：探針＋有信心的範疇
第N+1個衝刺：不確定的範疇（探針後估算）
6. AI故事的「完成的定義」
故事準備好可以估算的條件：
- 資料相依性已識別且可用性已確認（或探針已計畫）
- AI/模型方法已確認（或方法的探針已計畫）
- 與利害關係人已商定驗收門檻
- 已定義備用行為
結論
估算的精確性不如估算的誠實性重要。BA在AI估算中的角色是將不確定性結構化、在需要時提議探針，以及向利害關係人設定合理的預期——而不是強迫出一個沒有根據的精確數字。
AI團隊的衝刺速度通常因探針工作而比傳統功能團隊低20到30%。從一開始就將這點納入容量規劃中。