對於敏捷開發中的工程師和專案經理來說，“一個迭代該處理多少個故事（Story）？” 是常見的問題。敏捷方法已經運行多年，雖然沒有統一答案，但以下經驗法則或許能提供啟發。
每人每迭代完成多少故事？
根據 Mike Cohn 的文章 “Should the Daily Scrum Be Person-by-Person or Story-by-Story?” 提到的建議：
- 每位團隊成員在一個迭代中平均能完成 1 到 1.5 個故事。
- 假設你的團隊有 8 人，那麼一個迭代大約可以完成 8 到 12 個故事。
如何應用這些經驗法則？
以下是一些實際應用的要點，幫助你更好地規劃與執行：
1. 故事大小的切割
- 一個故事的大小應適合在 0.5 到 1 個 Sprint 內完成。
- 假設迭代長度為 2 週，則每個故事應該能在 5 至 10 天內完成。
- 若故事的預估時間接近上述範圍，表示你的故事切割得當，這能有效避免過大的範疇導致進度拖延。
2. 避免做不完的風險
- 為什麼故事的大小應控制在半個 Sprint 到一個 Sprint？
- 估算時經常會低估實際所需時間。
- 保留適當的緩衝空間有助於應對延遲，讓團隊能在迭代結束前完成故事。
3. PBR 要準備多少個故事？
- PBR（Product Backlog Refinement）是為下個迭代準備故事的重要環節。
- 根據每人每迭代完成 1 到 1.5 個故事的標準：
- 若團隊有 8 人，則在 PBR 中應準備 8 到 12 個故事。
- 避免準備過多或過少，以免浪費時間或降低迭代效率。
4. 大故事該如何處理？
- 若團隊選擇進行 Pair Programming（雙人編程）或處理較大的故事：
- 可以將每迭代的故事數目減半。
- 每兩人在一個迭代中完成 1 到 1.5 個故事。
- 減少同時進行的故事數量有助於降低 WIP（Work In Progress）。根據 Little’s Law，較少的 WIP 能有效縮短 Lead Time（交付時間）。
小結
確定迭代中處理的故事數量是一門藝術與科學的結合。透過控制故事大小、合理規劃 PBR 故事數量，以及善用經驗法則，能讓你的敏捷團隊更加高效，進一步提升產品開發的成功率。
參考文獻： Should the Daily Scrum Be Person-by-Person or Story-by-Story?
發表迴響