如何正确使用故事点预估工作量？

万事ONES

+ 关注

2021-10-21 10:29

785次阅读

在敏捷开发的过程中，研发团队需要对任务工作量进行相对准确的预估，从而科学把控项目进度，确保项目及时落地与交付。「故事点」是敏捷开发中一种有效的度量单位，它以数字的形式呈现，表示完成某个用户故事开发所需要的工作量。

与「工时」不同，「故事点」是一个抽象的、相对的值，它包含了对开发任务量、复杂度、风险和不确定性的整体预估。然而，由于每个人/团队的技术水平存在差异，对同一任务的复杂性和风险程度的判断也是不同的，因此每个团队对「故事点」都有自己的标准。一旦团队对「故事点」达成了共识，它能够帮助各个成员在估算工作量时快速达成一致，并有效地衡量团队产能。那么如何正确地对故事点进行预估呢？

选择基准故事，赋值故事点

我们所有人对「1个小时」都有清晰的认知和共识，因为时间是一个绝对值，然而「1个故事点」到底代表多少工作量呢？为了确定故事点的标准，团队需要先找到一个基准故事，该基准故事需包含解决具体用户故事所要完成的标志性任务，例如选择一个包含前端和后端任务，后端有数据信息交互的用户故事作为基准故事，其工作量设为1个故事点，那么其他用户故事则可以基于这一基准故事进行故事点的预估。比如某团队设置基准故事 A 为1个故事点，用户故事 B 的开发任务量、复杂度、风险和不确定性综合预估是基准故事 A 的3倍，那么用户故事 B 的故事点就应该设立为3。

故事点的取值需遵循斐波那契数列数列（1、2、3、5、8、13、21、34...), 为了避免繁琐，更好的体现故事点的差异性和准确性，团队可沿用修正版的斐波那契数列（1、2、3、5、8、13、20、40...）。

运用规划扑克，确定工作量

选择好基准故事之后，团队成员则可以开始对用户故事进行故事点估算。为了保证团队成员对同一用户故事的工作量判断达成一致，在故事点估算会议上，我们通常运用「规划扑克」的方式完成集体估算。

对于选定的10-20个待办事项，参会人员集体讨论其功能实现并提出问题，然后每个人对待办事项进行故事点预估，同时亮出扑克。对于同一待办事项，如果大家给出的故事点预估存在了很大的差异，代表大家对它的工作量、风险和不确定性、复杂度没有达成共识，估点高和估点低的人需要给他们一个机会阐述估点的理由。大家对该待办事项所包含的细节达成共识后，再对故事点数进行重新评估，直至大家对故事点数的评估基本达成一致。