Scrum sprint plan中规模估算的常见方式

首先，把根据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不久的团队和有新人的团队。