文章摘要

敏捷估算的挑战与工作量的定义

敏捷估算是产品和项目中不可避免的，但估算结果通常难以令人满意。文章从“工作量”（Effort）的定义入手，强调其与时间无关，而是完成任务所需的综合能量。传统项目管理中常将工作量与工时关联，而敏捷项目估算关注的是准确性而非精确性，强调动态调整的优势。

评估的准确性与精确性

文章通过靶子的例子说明了准确性与精确性的不同。在敏捷项目管理中，评估更注重准确性，因为项目初期信息不够清晰。通过sprint的动态调整，团队可以逐步提高估算的准确性，而精确性相对次要。

User Story估算的三个因素

文章介绍了评估User Story的三个维度：工件大小、技术复杂度和需求复杂度。这些因素帮助团队更全面地进行估算。同时，提出相对估算的教学方法，通过矩阵表和加权平均数的方式让团队了解相对估算的概念。然而，实战中绝对估算仍占主导地位，因为偏差可能带来误差。

斐波拉契数列在估算中的应用

斐波拉契数列常用于敏捷估算扑克。文章指出每个数字代表估算区间的可能性，而不是具体值。例如，“5”表示介于“3”和“8”之间的估算区间。这种方法虽然准确，但不够精确，尤其在区间较宽时不确定性增加。

数User Story个数法

Ethan老师推荐通过数User Story的方式进行估算，此方法适用于大小接近的用户故事。团队需要通过学习和练习保证稳定性，从而有效使用该方法。同时，利用AC（验收条件）个数对比工件大小，以及观察Gherkin语法中的前置条件来降低依赖关系。

技术债不应计入User Story

技术债不应作为User Story，因为其本质是没有直接价值的。文章强调每次Sprint应尽量不留下技术债。团队需在不留债务与集中还债之间权衡，以实现更高的价值产出。

Bruce Talk

查看原文：如何进行用户故事估算——10月9日Ethan Huang分享感受

文章来源：

Bruce Talk

扫码关注公众号