Scrum迭代计划会上有个重要的环节是团队扑克估时，估时是一种工作量化，同时更能明确的表明团队速率，每个迭代完成的用户故事数。

对于一个刚转型敏捷的团队，建议使用人/时的方式估时，如果是相对成熟的敏捷团队建议采用Story points(故事点)。

PO在计划会上讲解用户故事，Scrum Team理解用户故事业务逻辑，若有疑问，PO进行讲解以及解答。没问题后Team拆解子任务并预估时。按照经验用户故事一般按照前后端维度拆解，前端根据页面去拆解子任务，后端根据前端的页面提供对应增删改查接口，以及前后端联调子任务。如果是复杂的用户故事，建议按照业务流程涉及到的各个模块拆解。举个栗子：“作为运维人员，我想要设置定时任务，以便切换资源时可以设置自动从一主机组切换到另一主机组，并且可定时切回到原来主机组”用户故事，Team根据业务逻辑进行拆解。

其中后端子任务“详细设计”一般由该用户故事的开发负责人进行设计，包括数据库设计、接口设计、后端处理的业务流程等。

人/时估时

估计每一个团队成员在当前的Sprint中有多少时间可以用来冲刺用户故事是计划会Scrum master必做的工作。Sprint可用的工作时间= 平均日工作时间 - 其他活动。如果按照标准的一天8h工作制，扣除参加会议的时间，午饭、咖啡时间，意外的打断，看 email, 接听电话等等非工作计划时间，我们按照理想时间一天5h进行子任务开发估时。如果一个子任务超过10h的开发工作量，理论上要进一步拆解颗粒度更小的子任务。理想情况下，我们默认开发团队迭代内是没有bug，但是现实中肯定会存在当前迭代用户故事的bug，而这些bug的修复时间应该是包含在之前子任务的原预估时间里面。

对一个用户故事的几个子任务，Team可以采用扑克估时，比如后端的所有开发同学同时预估“新增接口”子任务，如果个别同学预估差异大，可以询问该同学怎么理解以及为什么这么估时，其他同学可以解答自己想法，之后再重新估时一次，达成普遍的一致。一般经过2轮估算，团队基本对任务耗时达成共识

Story points估算

人/时的估时对应到燃尽图是剩余预估时间的燃尽，只代表了开发进度，没有从整个用户故事从待办（需求提出）--研发--测试–上线全流程端到端进度管理。比如迭代回顾时剩余预估时间燃尽图已降至最低，用户故事全部code done状态，但是部分用户故事还在测试中，无法交付，按照敏捷中的规则，测试中的用户故事是未完成的，但是剩余预估时间燃尽图却看不出未完成的状态。因此我们引入敏捷故事点的概念，故事点可以衡量整个敏捷团队的生产率（迭代速率）

故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。当采用故事点估算时，我们为每个待办项分配一个点数，故事点是对用户故事的相对估算，而不是绝对数值。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。

由于故事点数代表了完成用户故事所需的全部工作量，所以团队的估算必须考虑到影响工作量的所有因素。这可能包括：

1.要开展的工作的数量

2.工作的复杂度

3.要开展的工作中存在的任何风险或不确定性

基于一个用户故事，开发团队（前后端开发+测试）都需要进行故事点估算，采用斐波那契数：1,2,3,5,8...，也可以利用微信小程序Scrum敏捷估算，不同职能成员站在不同的角度思考用户故事的复杂度以及风险，比如测试依赖外部系统数据等，然后给出自己理解的故事点数，如果是第一次实施故事点估算，建议选择最大的点数。具体估算方法可以参考上面的人/时估算，一般也是经过2-3轮可以确定一个用户故事的相对大小。参考之前故事点估算的经验，一般经过4-6个迭代后，就可以确定了团队交付速率，也就知道了团队一个迭代内可以完成多少个用户故事从开发到测试到部署。

故事点是一个相对抽象的概念，团队的理解以及运用对比人/时会难一些，建议团队可以同时采用2种估算方式，后续运用故事点成熟后可以考虑只用故事点估算。如果是同时采用2种估算方式，为了避免整个计划会时间过长，可以在Team对子任务预估时后，Scrum Master再组织架构师、部分开发人员以及测试人员基于预估时的结果进行故事点相对估算。

文章来源Scrum估算方法