首先，把根據sprint歷史數據得到的估算，稱為 歷史數據估算，把commitment之后的估算 稱為 承諾估算。
歷史數據是以前的定量情況，包括但不限于資源利用率、sprint可以完成的story point數量、每個story point平均所需的【實際】/【理想】人時（或工時）數、每個use case point平均所需的【實際】/【理想】人時（或工時）數，等等。
承諾估算是指團隊的每個成員達成共識，認為可以完成的估算，
對于 歷史數據估算，常見方式如下。
1，假設1個user story point需1個理想人天（IMD）， Velocity為理想人天數/實際人天數，常見的范圍是50%~80%。
sprint估算時，估算可用人天數 * Velocity 得到 user story points數量。
2，選擇最小的工作單元為1個User stroy point，velocity為user story points數量/理想人天數，再考慮資源
利用率，可能是75%左右。sprint估算時，估算可用人天數 * 資源利用率 * Velocity 得到 user story points數
量。
3，選擇最小的工作單元為1個User stroy point，velocity為user story points數量/實際人天數，不再考慮資
源利用率。sprint估算時，估算可用人天數 * Velocity 得到 user story points數量。
4, 采用use case point作為規模，Velocity為use case points數量/實際人天數，不再考慮資源利用率。
sprint估算時，估算可用人天數 * Velocity 得到 use case points數量。
5, 看看前幾個sprint完成的user story point數量，或采用平均數，或上個sprint的story points數量，或根據情
況在以前基礎上略作調整，這樣就不必管velocity的計算了。前提是團隊人員工作量投入變化小，人員穩定。

對于承諾估算，常見方式如下。
1，sprint planning part 2團隊將user story細分為task細分為task，用小時進行詳細估計之后，達成承諾。sprint planning part 1進行歷史數據估算。 具體的commitment是依賴于sprint planning part 2估計出來的hour-based capacity和effort來決定做哪些feature的。
2，歷史數據估算采用了IMD，按功能的優先級，本次Sprint要達到的目標，選擇優先級最高的功能，分解為實現任務，任務顆粒度是約2H~6H,并評估如何實現，不斷評審優先級最高的一些功能，直至Team不能承諾完成為止，也即是所選功能的累積IMD達到了 本sprint的IMD。
3，基于歷史數據估算進行調整或不調整，就算調整，幅度也不大，在20%以內，不細分任務到Hour-basde，最后團隊達成承諾。

小結
在多數的實踐中，“豬”們（scrum中意思，絕無其它意思）的承諾都基于歷史數據估算，就算是第一個sprint的估算，也參考了非敏捷生命周期或業界的數據。承諾估算雖然會調整些，但幅度都在25%以內，多數情況下幅度小于5%。
歷史數據估算在sprint plan時看起來是不可少的，顆粒度到達6H以下的承諾估算很難單獨應用。
把歷史數據估算的結果（包括微調）作為承諾來達成，不失為一種可行的做法，尤其適合引入scrum不久的團隊和有新人的團隊。

總結

以上是生活随笔為你收集整理的Scrum sprint plan中规模估算的常见方式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。