近年来，Scrum 世界发生了巨大的变化。这一点在工时评估（estimating）方面体现得最为明显；自这个框架诞生之日起，Scrum 从业者就一直在进行着这项艰苦的实践。许多人没有看到评估的价值。2020 年，在 Scrum 指南中，“工时评估”一词被 “规模评估”（size）取代。有人些经常忘记评估是什么，说到底，评估只是评估。
社区对于工时评估和预测所持有的观点令人担忧。我的目的不是火上浇油，而是补充一些想法，以供进一步讨论。在我看来，Scrum 世界需要这样一篇文章。这是一篇理论性文章，适合有相当 Scrum 知识和实践经验的读者阅读。希望这篇文章对你有所帮助。
如果你做的预测总对，那你就是超级天才了。预测很少完美，原因如下：
由于存在依赖关系，所以等待时间是工作耗时的一个重要因素，受许多不可预测的事件影响。
即使工作环境不复杂，人们也会高估一天能够完成的工作量。
通常情况下，人们会设法尽快把复杂的工作干完，不讲条理，而且可能发生意外情况（意外并发症）。甚至更糟糕，后续的工作导致情况恶化，不管是否解决了杂乱无章的问题，工作耗时都会比之前多。有人称之为“破窗综合症”。
复杂的工作涉及许多未知的变量。
缺乏专注，例如，“拿出你 10 秒的时间“或者”务必想尽各种办法“，原因是发布周期太长或者围绕流程瓶颈的过度计划（工作太多）。
改变优先级，而又没有根据调整后的优先级更新工作量。例如，在有问题的预测会议之后，且明显不允许的情况下，又增加了一个新的优先事项。
人们通常认为，预测是为了告诉大家，“什么时候可以完成？”然而问题经常会接踵而至：
我如何才能把担忧传递给别人？
取得了哪些进展？
还有什么风险？
对于这项投资，我们什么时候才会有回报？
哪些工作有潜在价值，如 80:20 原则，对此我们可以接受何种取舍？
部分或全面降低有效性、效率和可预测性，如运行一些试验，对此我们可以接受何种取舍？
我们需要通过“非生产性工作”来避免执行偏差，如试验室准备，对此我们可以接受何种进度取舍？
为了掌握所需的技能，我们需要多大的投入，如培训或学徒训练？
有必要考虑下“赢得游戏意味着什么？”这个问题的元问题。团队参与的是一个有可能获胜的游戏吗？如果团队能够获胜，胜算有多大？概率预测可以提供帮助，如蒙特卡罗模拟算法。
尽管存在风险，但团队有时还是需要预测，因为人们担心，利益相关者会凭空定一个不可能完成的日期。有时候，团队希望有一个超出利益相关者预期的大致日期范围。有趣的是，大多数人都可以接受天气预报随着最新信息定期更新，即使我们知道那还是不准确。
蒙特卡罗模拟
Troy Magennis 对蒙特卡罗模拟做了很好的解释，简而言之，它让人们可以基于数据和假设“模拟（model）”未来。概率预测可以告诉你，你能够完成多少工作，而不是你手头的工作是否符合预测。虽然对于复杂的工作来说，概率预测是一种幻象，但我们可以在掌握最新信息时重新做，让它们随着时间的推移越来越可靠。
“Monte Carlo-When”预测使用 500 到 100 万个随机数表示每个时段内介于上下限（真实数据或 90%置信猜测）之间的吞吐量（每个时间段内，如冲刺，有价值事项的交付率），以及随机生成的一定范围内的事项数量，每个预测将返回一个日期范围以及相关的概率。例如，在下图所示的结果中，经过 10k 次模拟，在 11 月 22 日或之前有 85%的可能交付 50 到 75 个事项。
“Monte Carlo-How Many”预测使用随机生成的每个时段中一定范围内的吞吐量，来预测给定日期内可以完成多少事项；输出是一个日期范围、截止那个日期可以完成的事项，以及一个百分比概率。如下图所示，85%的事项将在那个日期或者之前交付。
不管在哪种情况下，限值错误都会导致预测质量不高。例如，我们使用一个七面的骰子，点数为 1、2、3、4、5、6、7，而吞吐量只有可能是 3、4、5、6 或 7。我们也允许出现 1 或 2，只是那可能已经超出了限制。也就是说，1、2、8 或 9 还是可能出现，只是可能性比较小。Prateek Singh 更详细地介绍了如何使用各种模型来生成随机数。此外，如果吞吐量不稳定，或者每个时段都几乎为零，那么蒙特卡洛模拟的质量就会大大降低。预测的本质是风险管理。它回答了这样一个问题：我们目前的计划包含多少风险？预测质量下降也就意味着风险管理不足。
社区并不认可这种方法。一个项目仅执行一次。虽然概率可以帮助我们做决策，但问题是它们并不会简化决策过程。评估经常作为决策的一个指标（我们要不要做这个项目？）。在这方面，概率预测会提供什么答案吗？还是说只会提出更多的问题？这些问题很重要，但使用估计的原因与概率预测并不相同。我见过许多基于错略评估、缺少历史信息的概率预测，最终还比较准确。如果你想了解更多这方面的内容，可以看下我和Troy Magennis的有关对话。
接下来，我将更详细地介绍工作量评估和预测，希望可以帮助大家了解 Scrum 语境下的小恶魔。
工作量评估技术
在使用 Scrum 时，Scrum 团队是自管理的，开发人员负责评估工作量，因为他们最熟悉开发工作。
最流行的工作量评估技术要么是基于数据，要么是有依据的猜测。要知道，在面对复杂情况时，这些技术一般都不准确。
我发现，大部分人都不擅于估计。尽管如此，人们还是可以从对话中感知到价值，当我们就工作及其挑战达成共识时，就可以做出一些假设。“理解事项”和“评估事项”是两项单独的活动，不应该混为一谈。我认为，针对单个产品待办事项的评估并不能为预测完成工作需要多少时间提供一个坚实的基础。
下面是使用估计进行预测时最流行的工作量评估技术：
相对估计时间参照——将当前事项与完成历史参考事项所用的时间进行比较。分配数字值——例如，使用基于斐波那契数列的故事点，并经常搭配扑克牌方法（计划扑克）使用。T 恤尺码分类法——给待办事项列表上的事项分配尺码（s、s/m、m、m/l、xl、xxl、xxxl、xxxxl）而不是数值，有时候，为了简单起见，我们会去掉一些尺码，只保留 S=1、M=3、L=8、XXL=20（四舍五入）、XXXXL=60、?=100（四舍五入）。墙壁估计（Wall estimation）——通过一起在墙上放置和移动卡片来分配数字值，也称为魔法估计或沉默估计。
流量计（Flow metrics）或事项计数对于一个目标或时段—— （尽可能）识别/清点待办事项列表上需要完成的事项数量或范围。
适型化（Right-sizing）—— 识别出足够小的事项以供团队纳入工作计划——通常使用一种基于流的方法—— 一个事项是小号还是中号并不是那么重要。这项实践是为了弄清楚，根据完工定义，团队能否在一次冲刺中舒畅地完成一个待办事项。
#NoEstimates —— 一种解释是：争取让待办列表上的事项“大小合适”且均匀分布。数一下现有已测故事或特性，展示输出进展。以“为什么”为目标，致力于简化“是什么”，即聚焦预期成果。适型化 —— 识别出足够小的事项以供团队纳入工作计划。将事项切分到 24 小时的时间框里，鼓励创建试验，验证为达成目标所做的假设和猜测，了解情况以便交付。使用滚动预测来沟通不确定性。
有人会认为，只清点待办列表事项而没有吞吐量数据还是一种估计，我对此表示赞同。基于已完工事项的吞吐量计数是一种预测。
在上面的工作量评估方法中，只有墙壁估计直接考虑了相对潜在价值。它使用价值点来评估价值（而不是工作量）。价值不是绝对的，而是相对的。客户价值只有在发布给客户之后才能实现，而其价值可能高于预期，也可能低于预期。
上述所有的评估方法都会因以下情况贬值：
没有与开始日期相关的说明，如从开始之日起 9 周。
没有识别出在制品的数量及其进展（或者没有进展）。
障碍的严重性。
没有根据交付风险大小对产品待办列表的事项做降序排列。
没有用最好的方法来处理依赖关系。
将输出与成果混淆；客户/最终用户成果是他们的行为变化。
当无法获取潜在价值的风险很高时未参加发现活动，而假定所有事项都从发现移到交付使情况进一步复杂化。
妄想准确，还追求更准确。
以下趋势并不是很理想：
按技能评估——通常是因为关注资源效率胜过流程效率。
大小通胀——通常由迫于压力“提速”所致。在非典型情况下，团队在评估工作量大小时会就高选还是就低选？不用猜，很可能是就高选。在极端情况下，我称之为（评估）Bingo。
不重视质量，例如，完工定义缺乏一致性——通常由迫于压力“提速”所致。别搞错了，完工定义的质量承诺很重要。
不重视客户，例如，交付输出却不衡量效果——通常是由“楼内思维”过盛或远离客户所致。
团队之间大小标准化，通常是因为把人当成了可替换的机器零件。根据我的经验，在很多情况下，即使产品待办列表、比较参考项和范围都相同，团队也从来无法得出相同的大小评估。
清点已完成的伪产品待办事项（不提供价值的事项）作为吞吐量——通常是由使用了忽视价值的工作分解结构所致。
不专注，未完工。在 Scrum 中，专注很重要，这主要体现在产品待办列表中的产品目标、冲刺待办列表中的冲刺目标以及 Scrum 价值。专注于已经开始的工作，即使那意味着分割或取消工作，如何？
妄想预测无法与以前比较的工作。
未能通过发现找出我们可能不应该构建的事项，有人说是 70%。我们可以通过低成本的试验获得更好的想法。例如，据我所知，当 Bose 发现降噪耳机时，他们其实是在寻找提高声音保真度的方法。缺少发现通常是因为领导者致力于代表团队工作；他们的观点是，“寻找更好的方法没有意义，我们有最后期限。”
这篇文章不是为了帮助人们保持这种趋势，而是要介绍更好的方法。需要注意的是，本文介绍的内容并不能帮助你更好地使用故事点进行评估。
本文将重点介绍的三个工作量评估选项是估计、适型化和 #NoEstimates。没有哪一种方法是完美的。我还考虑了其他一些选项，但无论采用哪种方法，准确度都很低。
关于估计：估计有不同的方式。如果进行估计，最好的结果就是估计对了。而事情要用多长时间和处理时间几乎是没有关系的（参见Troy Magennis探讨这一主题的文章）。估计容易出现“平均值缺陷”（萨维奇）。采用五五开的方法设定期望值好吗？独立盲估的平均值可以足够接近真相（参见Dave Snowden的Xagility播客）。但估计很少是盲目的。如果你根本不进行估计，就可以节省时间；希望你能更快地发现/交付成果。
关于适型化：如果你能更多地关心团队能否在冲刺中完成一项工作，而不是想尽办法压缩这项工作，那能节省多少时间？要考虑到 PBI 数量少可以减轻产品所有者的认知负荷。清点一下每个冲刺要完工交付的 PBI 数量（有价值、大小合适），这对于冲刺规划和目标预测很有价值。如果吞吐量断断续续或者无规律，那么我们面临的问题就会比预测严重；我们会面临“管道问题”。使用平均吞吐量也会导致“平均值缺陷”。蒙特卡洛概率预测法更可取。
关于 #NoEstimates，一种解释是：清点一下每个冲刺要完工交付的 PBI 数量（有价值、大小合适），这对于冲刺规划和目标预测很有价值。如果吞吐量断断续续或者无规律，那么我们面临的问题就会比预测严重；我们会面临“管道问题”。基于有变化限制的吞吐量进行”滚动预测（Rolling Wave Forecast）“更可取。
不管是使用估计、适型化还是 #NoEstimates，有时候产品待办事项（PBI）很难拆分，所以它们仍然有价值（而不仅仅是子任务）。介绍如何拆分产品待办事项的指南有很多。实例映射就是一种很强大的方法；Scrum 团队可以仅为这个冲刺选择一个实例，并获取反馈。当我们可以收获价值的证据不足时，即使潜在价值很高，明智的做法也是借助试验通过推测（hypotheses）来验证假设（assumptions）；#NoEstimates 和 Scrum with UX 支持这种方法。拆分可以引发发现或是发现-交付（discover-to-deliver）。例如，拆分可能引发客户访谈和 UX 研究。
部分评估方法的潜在优点
部分评估方法的潜在缺点
评估方法的其他注意事项
预测
在预测工作量时，最受欢迎的方法往往是基于：
产品待办事项（PBI）完工数量/范围的过往表现，基于平均值或范围——过往的表现不能预测未来，但短时间内（如一个冲刺）还可以。
TWiG and ActionableAgile的截图 —— 团队在交付，但许多天没有交付完工内容。
数字值或 PBI 完工数大小/范围的过往表现过往的表现不能预测未来，但短时间内（如一个冲刺）还可以。对数字值做算术运算要谨慎，因为复杂性会随着产品待办事项的大小呈指数级上升，把“大象”事项纳入冲刺是有问题的。注意正在进行中的 PBI 的数量。有时根据燃耗/燃尽图，使用剩余工作随时间推移的“精确”/相对大小。
燃耗/燃尽图是基于平均数的，经常被误解
概率预测（使用百分比概率）用于预测一定数量（或范围）的事项在不同日期完成的不同概率；可用于短期、中期和长期预测。考虑使用参数比例或随机抽样，根据以前的工作进行建模。例如，你可能会想：这项投资感觉和以前的两项投资类似，但我们需要增加 15 个事项。还要考虑将所有东西整合在一起的事项的数量或范围，因为工作最终整合时并不一定那么容易——但无论如何，风险不是通过迭代、增量和持续交付得到了很好的管理吗？
概率预测用于预测在特定的时间内可以完成多少 PBI——包括一个百分比概率、一个日期以及截至该日期可以完成的事项数量（或范围）；可用于短期、中期和长期预测，但它更适用于输出导向而不是目标导向。
滚动预测证明了同时预测可能性和不确定性是门艺术。
可以这样说，“我们采用一种经验性的方法，一次处理一个冲刺；冲刺目标并没有什么保证；真正的答案是，我们不知道，但让我们开始并快速学习吧。“你可能都不会用到“现在？”、“下一步？？”、“其后？？？”这样的字眼。
在预测过程中，最令人不快的部分是，它通常不考虑我们同时进行的 PBI 有多少个。唉，我也经常看到一些团队，承担了超出他们通常能力的事项。
如前所述，团队可以使用不同的方法来评估工作量，实现冲刺/产品目标。几乎可以肯定，预测是错的，所以它们传达的是不确定性，这是为了提醒利益相关者，他们正在使用经验性的方法，一次一个冲刺的前进，而且要经常更新预测。（希望）产品待办事项成为一件有生命力的神器。
可能有人会说，最好的做法是根本不预测。他们会说：“我们只需发现并交付功能——与客户和最终用户一起评审成果。能学什么学什么。根据我们的发现采取行动。不做什么预期管理。”
结论
避免使用故事点方法。如果必须要使用故事点，那也只能当做一种临时性的方法。流行的做法是，将故事点方法作为团队工作量评估技术的一种补充，但它不能作为 Scrum 的一部分。我不喜欢这种方法。据我观察，当人们使用故事点时，经常会有破坏性的行为。我看到，人们使用故事点通胀、故事点 Bingo、故事点标准化和故事点速度作为衡量绩效的指标。举例来说，高层领导希望提升速度，所以他带领团队成员拆分未完成的事项，为的是达到某种故事点速度水平。团队无法完全控制他们可以交付多少工作。因此，如果一个团队面临着提升速度的压力，那么一个中等事项被定义为大型或超大型事项的几率就会增加。
避免使用平均吞吐量方法。吞吐量方法比故事点方法好一点，虽然它也不完美，但在与概率预测和吞吐量有价值事项计数一起使用时，它是一个更准确的预测基础。不过，如果事项无价值或大小不合适，那么吞吐量的可信度就会降低。吞吐量方法不是 Scrum 的一部分，在看板指南中也是可有可无，对于非软件行业，应考虑为不同类型的产品待办事项单独计算吞吐量，如包装 vs. 运输。用平均值来预测时间/点数/吞吐量可不是什么干事业的好方法。“老板，我们准时交货的概率是 50%；这样可以吗？”
考虑使用历史参考项。历史参考项包括“等待时间”，使用该方法的前提是记住了它消耗的时间，不过意外并发症不在考虑之列。意外并发症是指我们的遗留工作比较杂乱，间接影响了估计质量；这也是参考项用于时间估计效果不是很好的原因。
尝试将有价值事项吞吐量作为概率预测的基础。对于非软件行业，应考虑为不同类型的产品待办事项单独计算吞吐量，如包装 vs. 运输。对于复杂的工作，这仍然是“雾里看花”，所以你最好加一条声明：你将随着了解的深入，在下周和下下周提供更好的预测。在进行概率预测时要警惕虚假吞吐量（无价值事项吞吐量）和散发吞吐量，特别是当所选的大多数时间段吞吐量为零时——基于不稳定的吞吐量进行概率预测会大大降低预测的质量。
尝试 #NoEstimates——滚动预测很好地传达了不确定性。为了避免破坏 Scrum 或看板（如使用 Scrum 团队看板指南），务必要确保所有（产品待办）事项都有价值。
当有人问你，团队何时能完成某件事时，试着回答说你不知道。但你得向他解释，你使用的是基于证据的经验主义方法，并且一次一个冲刺/周/月。许多事项需要发现/Spike（探针）；你不知道会得到什么反馈，你不知道会学到什么，你也不知道要如何回应。但请注意，在许多文化中，人们都习惯于把真空填满，如果没人提供预测，其他人就会急切地等待，而且可能会一直等下去。
宜以敏捷为榜样。了解问题空间。发现并交付功能——与客户和最终用户一起评审成果。能学什么学什么。根据我们的发现采取行动——设定对不确定性的预期，而不是日期，让相关人员知道，这在某种程度上是在赌博。不要总想着了解我们不知道的东西。正如一位著名的敏捷专家对我说的那样，预测让我们觉得自己在做一些有用的事；这种感觉或未满足的需求都是我们要解决的。
我们经常会在估计和预测时迷失方向，忽略了价值。我们要和受影响的人一起衡量工作是否发挥了作用并适时做出调整。
附录
流量计
流量计不只是与吞吐量有关。根据 Scrum 团队看板指南，你还可以关注在制品、周期时间和事项年龄；在这种背景下，只看吞吐量是短视的。即使在 Scrum 背景下，只关注吞吐量而忽略受阻或被遗忘的产品待办事项也是很愚蠢的。
Scrum 团队看板指南为 Scrum 引入了 4 个指标，包括：
在制品（WIP）：已经开始但尚未结束的工作事项。团队可以使用 WIP 指标来展示进展，减少在制品，改进工作流程。请注意区分 WIP 指标和 Scrum 团队用于限制 WIP 的策略。
周期时间：根据 Scrum 团队看板指南，周期时间是一个事项从开始到结束所消耗的日历时间（四舍五入）。
事项年龄：一个事项从开始到现在所消耗的日历时间；它只适用于正在进行中的事项。
吞吐量：单位时间内完成的产品待办事项数量。
参见：Scrum with Kanban如何帮助人们解决复杂问题？
一些影响/挑战预测的技术
工作量评估指南——其他方法
其他评估方法的优点
其他评估方法的潜在缺点
其他评估方法的其他注意事项
作者简介：
John Coleman 是X-agility和Orderly Disruption的敏捷大厨。同时，他还是一名博文作者和播客创作者（Xagility™、Agility Island）。John 是Thinkers360的十大敏捷思维领袖之一。他最擅长管理层敏捷性、真正可持续的组织敏捷性、降规模（descaling）和度量。John 经常使用 Scrum、看板或精益 UX。他曾设计方法，供那些需要保护措施或纯粹基于价值观或原则运作的团队使用。John 是看板指南的合著者，同时也是 Kanplexity™的作者。他是 Scrum.org 的专业 Scrum 培训师、Prokanban.org 的专业看板培训师，同时也是一名 LeSS 友好的 Scrum 培训师。
原文链接：
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论 3 条评论