首先，把根據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不久的團隊和有新人的團隊。