估计占位符故事是一种糟糕的实践

占位符故事通常都不是一个好主意。估计占位符的故事储备能力或者获得学分这是一个非常糟糕的主意。

定义“占位符的故事”

当然，所有的故事都是“对话的占位符”，但这不是我在这里要说的。

我也不是在谈论像“在我们开始做什么史诗时重构什么类”这样的事情。我并不是说你有一个已知的客户问题，但却不知道该怎么做，如果有的话。这些都是可以明确识别的工作。这些应该在待定项中(为了冲刺或发布)，我不把它们称为占位符。

我并不热衷于在sprint或发布计划安排中使用时间跟踪故事，因为它们需要从某些指标(如已完成的故事数量(吞吐量))中退出。但我理解组织为什么要这样做。让我们把这些时间追踪故事叫做故事而不是占位符。

所谓“占位符故事”，我指的是关于已知-未知(或未知-未知)的故事，例如:

-我们知道我们有一些生产支持工作要做…2点

-我们可能需要做一些销售支持…1点

-我们知道我们将不得不处理一些在sprint期间出现的高优先级缺陷…3点

-我们可能会因为一些高优先级的加速工作而被打断…保留8分

build服务器很脆弱，可能会再次崩溃，2分

“我们可能要做的其他未知工作的占位符故事”……3分

-发布结束回归测试…60点

我主要抱怨的是对它们的估计。

能见度很好

我曾见过一些团队在每个sprint中放置一个占位符故事，作为保存客户电话记录的地方(主要是为了获得信用)。他们将为每个新的支持调用在描述或(子)任务中添加一行。在这个例子中，我并不完全反对占位符故事本身，因为它其实只是另一种时间追踪故事。此外，通过子任务使工作可见也是一个好主意。但估计它是靠不住的。

负面影响发布计划

速度对于sprint计划来说是一个有用的输入，但是它对于发布计划来说更加重要和有用。如果速度包括缺陷和其他占位符，那么发布计划实际上会变得更加困难。

跟踪PO可以依赖的速度，以及缺陷和其他占位符会让人感到厌烦，并且容易出错。

当产品负责人考虑一批故事(例如，一个新特性或一个史诗)的成本或持续时间时，PO不能只是做简单的计算(待办事项规模/速度)。他们需要有人把占位符故事放到史诗中或者他们需要有人告诉他们真实的用户故事的速度是多少。

占位符让我们更难为发行设定假设场景:“如果我们削减一些范围并将发行日期推迟2个月会怎样?如果我们将发行时间延长1个月呢?”我们必须考虑占位符在backlog中的位置，并将其放大或缩小。或者如果每个未来的sprint都有一个占位符，那么我们就会有很多占位符污染我们的backlog。

估计占位符会导致你的速度膨胀的相对于发布的已知工作的积压。不估计已知-未知的占位符将简化发布计划。

因此，不要在你的速度中放置占位符垃圾。如果你为发布计划的目的使用速度或吞吐量如果你正在做出任何发布承诺，那么你的速度度量应该只计算有价值的故事——产品负责人或客户想要的backlog中的项目，故事图中的项目以及史诗/功能/故事分解中的项目。

不需要权变

有些人在发布计划中使用预估占位符进行缓冲。他们必须这样做，因为他们在所有事情上都加了分数，在所有计划外的事情上也加了分数。不要估计这些东西。没有计划和未知的东西应该较低的你的速度。

跟踪生产支持的历史速率与您的速度分开。跟踪不良率。了解跨发行版的趋势和发行模式。然后在制定发布计划时考虑到这一点。例如，这些信息可以帮助我决定使用什么作为我的计划速度，在平均值中包含多少或哪个sprint，以及是否进一步调整它。它还帮助我决定要计划多少个积极开发的sprint。如果你在发行版的最后花了一周或几个sprint来做回归测试，那就在你的时间表中做好计划。你不需要在上面加分。

在发布日期更改时移动占位符，并在缓冲区被消耗时调整占位符，这非常令人厌烦。更糟糕的是，这种复杂性会为错误创造不必要的机会。

保守地计划发行:不要在你的速度中包含已知和未知;但是要在你的发布计划中包含已知的未知因素。

Sprint计划不需要

通常当团队使用占位符时，是因为他们想要估算工作的描述点，以便在sprint中预留一些容量。在每一次冲刺中都添加一个占位符，并将其称为2点储备容量是没有必要的。

根据产品负责人希望你在上一个sprint中完成的计划点数来规划sprint。如果你在使用(子)任务时估计了时间，并以小时为基础进行消耗，那么就降低你处理这些未知事情的能力，但要以你在之前的sprint中能够完成的已知任务的计划时间为基础。

如果构建服务器不稳定，或者需要对VM服务器进行维护，要么修复，要么不修复。不要为了以防万一而在你的冲刺中放置一个占位符。这是糟糕的计划。

不是相对估计

相对估计在比较已知的工作和实际的用户情景时起作用。你不知道你会遇到多少生产支持问题，也不知道解决这些问题需要多长时间。估计这些东西远不如估计已知的东西准确。一般的生产支持和其他开销不应该显示为估计你的sprint或发布backlog中的项目。让支持活动拖累你的工作速度。

缺陷和加速是什么?

一旦有一个特定的问题需要修复——一个已知的已知的问题，缺陷就会出现在您的backlog中。同样，高优先级加速工作。一旦它成为一个已知的，就把它添加到你的冲刺中。

但不估计的缺陷．就让它们拖累你的速度吧。分别跟踪历史的缺陷率。您可以在您的sprint和发布计划中预留容量，而不需要为尚未发现的缺陷预留位置。

从完成的工作中获得奖励

如果你的团队正在使用和估计占位符来获得荣誉，阻止这种情况的发生。如果人们觉得有必要提高自己的工作速度或获得荣誉，这就是组织中的一种功能障碍。

结论

没有理由在占位符故事上加点。把计划外的东西排除在速度之外。这将导致更简单和更保守的发行计划。