如何通过相对规模来估算用户故事？

事实上，如果没有一个好的系统或者工具，我们很难估算用户故事，甚至经常高估或低估了自己要做的工作。而对于那些需要花数周或数月时间制定长期计划的传统公司来说，一旦工作出现中断，必然会偏离最初的估算。

作为一个敏捷团队，可以 通过精准的迭代和看板上的在制品来避免长时间的、不可预测的计划周期。尽管这些敏捷实践更具灵活性与适应性，但用户故事估算在交付过程中的重要性也不能忽视，因为它是与领导沟通工作交付时间的唯一方式。

随着时间的推移，估算能帮助我们了解团队的速度，这样我们就可以更准确地预测工作。而通过引入相对规模，我们可以更好、更快地进行估算。

一、我们要估算什么？

敏捷团队会估算每个用户故事，并将其写在用户故事卡上。

用户故事是对客户所需功能的简短描述，用户故事卡是根据用户故事为敏捷团队显示某一交付单元的卡片。对于敏捷团队来说，他们要估算每一个故事的大小。
为了确保我们不会花费了大把时间做计划，结果因为不能适应这个计划转回到瀑布方式中，我们需要一种更直接的方法来评估用户故事。

如果团队刚开始做用户故事估算，一般会倾向于以小时为单位进行思考。但这其实行不通，因为我们通常在预测时间的时候是不太准确的。这也是比起马拉松式的计划，我们更喜欢短的迭代周期的原因之一。

如果故事的大小不能与小时挂钩，那我们如何估算用户故事呢？这里其实建议大家使用相对规模来估算。

二、什么是相对规模？

我们先来看一下这个术语的两个组成部分：规模和相对。

首先，故事的大小是需要估算的，由三个因素组成：

• 努力：完成这项任务需要做多少工作？
• 复杂性：这个任务有多困难或复杂？
• 不确定性：我们是否确切地知道要完成这项任务必须做什么，或者我们是否需要边做边学？

综合这三种因素考虑出的故事大小就是故事的规模。

其次，故事的大小是相对于团队其他用户故事来说的。

也就是说，我们可以通过多个用户故事的比较来确定哪个用户故事更大或更小，而不是在没有参考的情况下单独给故事规划大小。

三、水果沙拉游戏

对于初用相对规模估算的新手来说，我们可以用一个简单的游戏来介绍这个概念。

现在有一个需求是我们要带一份水果沙拉去参加聚会，且目前手中有几种水果：一个苹果、一串葡萄、一个菠萝等等。那我们现在需要将每一份水果都准备好，这包括清洗、去核、切块、剥皮等等。

那我们每次都只能拿到一种水果，并需要估算处理这个水果的任务的大小，这里的估算要考虑处理这个水果的工作量、复杂性以及不确定性。

首先我们先标记出所有规模：
然后我们来处理苹果。因为要花几分钟的时间来给苹果去核、切块，所以我们 可以先将苹果标位中等大小。这个任务并不是很复杂。
接下来需要处理葡萄。对于处理苹果来说，可能清洗葡萄会更为容易一些，葡萄只需要清洗一下并去掉它的根茎。
接着需要处理樱桃、西瓜、菠萝等，依次确定这些任务的大小。
在自己对所有水果的任务有一个大致标准之后，可以在团队之间交流彼此的看法，比如一个团队成员认为处理葡萄的任务复杂程度应该大于处理樱桃的任务，因为葡萄需要一个一个摘下来清洗并去籽。但是另一个团队成员则认为葡萄不需要去籽，因此任务比较轻松。

那在这些不同的观点提出之后， 团队就需要明确一个制作沙拉的标准：葡萄需 不需要去籽？苹果需不需要去皮等等。在统一了标准之后，大家再就任务实现估算的对齐。

在实际的项目中，我们可以运用做沙拉的思维，比如哪一个用户故事可以定位中等规模的用户故事，并以此设定一个标准的用户故事规模。同时将其他用户故事与该用户故事做比较，确定其他用户故事的规模。在了解了如何通过相对规模来估算用户故事之后，不妨在实际的团队中试一试这个方法吧~

*该文为翻译文章，原文链接：https://www.leandog.com/blog/how-to-estimate-agile-stories-relative-sizing