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

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

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

我们所有人对「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...）。

ONES Project 支持新建「用户故事」，并提供斐波那契数列帮助研发团队进行故事点预估，满足企业在敏捷研发场景下的需求管理。

ONES Project 支持斐波那契数列预估故事点

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

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

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

持续磨合，度量团队迭代效率

团队针对故事点的估算是需要不断磨合的，在迭代开发过程中，我们可能会发现故事点的预估出现了偏差，但此时不必急于修改故事点数。经过几次迭代的经验累积，团队会对于故事点的预估更加得心应手。

运用故事点预估工作量，还能够帮助团队度量迭代速率，从而更合理地规划版本发布。例如在多次迭代后，我们发现了团队在一个迭代中可以完成20个故事点，那么一个100个故事点的里程碑版本则预计需要5次迭代。

当然，团队的迭代速率并非一成不变，ONES Performance 基于团队的研发数据，可视化展现不同项目、团队、成员的故事点完成情况，科学度量团队研发效率。通过故事点完成量的对比，分析原因，总结经验，助力团队提升研发效能。

ONES Performance 支持「故事点完成量」报表

项目管理的过程中，一款合适的项目管理工具能够帮助团队实现效率最大化。ONES 研发管理工具为企业提供了完善的敏捷研发管理解决方案，帮助企业提升研发管理效能，更好的管控项目进度，保证项目研发过程的标准化、透明化及可视化，助力企业更好更快发布产品。

想了解更多 ONES 敏捷研发管理解决方案，欢迎访问官网 https://ones.ai/ 或点击阅读原文免费试用。

相关阅读：

ONES CTO 冯斌 | 敏捷思想是不确定时代的通行证

敏捷里为何倡导固定迭代周期？

即日起 Jira、Confluence 正式停售本地版，中国客户将无法购买

点“在看”给我一朵小黄花