一般来说，占位符故事不是一个好主意。 估计 占位符故事 以保留容量或获得信用 是一个非常糟糕的主意。
定义“占位符故事”
当然，所有的故事都是“对话的占位符”，但这不是我在这里所说的。
我也不是在谈论诸如“在我们开始研究某物或另一个史诗时重构这样的类”之类的事情。我不是在谈论有一个已知的客户问题，但还不知道该怎么做，如果有的话。这些是具体可识别的工作。这些应该在待办事项列表中（用于冲刺或发布），我不称它们为占位符。
我对在 sprint 或发布积压中使用时间跟踪故事并不狂热，因为它们需要从某些指标中退出，例如完成的故事数量（吞吐量）。但我理解为什么组织拥有它们。让我们称这些时间跟踪故事而不是占位符。
我所说的“占位符故事”是指已知-未知（甚至未知-未知）的故事，例如：
-
我们知道我们将有一些生产支持工作要做...... 2 分
-
我们可能需要做一些销售支持…… 1 分
-
我们知道我们必须处理冲刺期间出现的一些高优先级缺陷……3分
-
我们可能会因为一些高优先级的加速工作而被打断……保留 8 分
-
构建服务器很不稳定，它可能会再次崩溃……2分
-
“我们可能不得不做的其他未知工作的占位符故事”……3分
-
发布回归测试结束... 60 分
我的主要抱怨是估计它们。
能见度好
我见过团队在每个冲刺中放置一个占位符故事，作为一个地方来记录他们的客户电话（主要是为了获得荣誉）。他们会在描述中添加一行，或者为每个新的支持电话添加一个（子）任务。在这种情况下，我并不完全反对占位符故事本身，因为它实际上只是另一种类型的时间跟踪故事。此外，通过子任务使工作可见是一个好主意。但估计它是靠不住的。
对发布计划产生负面影响
速度是冲刺计划的有用输入，但它对发布计划更为重要和有用。如果速度包括缺陷和其他占位符，发布计划实际上变得更加困难。
跟上 PO 可以依靠的速度以及缺陷和其他占位符的速度会变得令人厌烦并且容易出错。
当产品负责人考虑一批故事（例如，新功能或史诗）的成本或持续时间时，PO 不能只做简单的数学运算（积压大小/速度）。他们必须要求某人将支持工作的占位符故事放入史诗中，或者他们必须要求某人告诉他们真实用户故事的速度是多少。
占位符让发布的假设情景变得更加困难：“如果我们缩小一些范围并将发布日期提前 2 个月会怎么样？如果我们加快发布速度并将发布时间延长 1 个月会怎样？”我们必须考虑占位符在积压工作中的位置，并将它们放大或缩小。或者，如果每个未来的 sprint 都预先放置了一个占位符，那么我们就会有很多占位符污染我们的积压工作。
估计占位符会导致您的速度相对于发布的已知工作积压被 夸大 。不估计已知-未知的占位符将简化发布计划。
因此，不要在你的速度中放置占位符垃圾。如果您 将速度或吞吐量用于发布计划目的 ，并且您可能应该做出任何发布承诺，那么您的速度指标应该只计算有价值的故事——产品负责人或客户想要的待办事项清单中的项目，您的项目故事地图和您的 Epic/Feature/Story 分解。
不需要应急
有些人使用估计的占位符在发布计划中进行缓冲。他们必须这样做，因为他们对所有事情都加分，对所有计划外的事情也加分。不要估计那些东西。计划外和未知的东西应该有助于 降低 你的速度。
跟踪生产支持的历史速度与您的速度分开。还要跟踪缺陷率。了解整个版本的趋势和分布模式。然后在制定发布计划时考虑到这一点。例如，这些信息可以帮助我决定我的计划速度使用什么，平均包含多少或哪些冲刺，以及是否进一步调整它。它还帮助我决定要计划多少个积极开发冲刺。如果您在发布结束时花一周或几个冲刺来进行回归测试，只需在您的日程安排中为此做好计划。你不需要在上面加分。
随着发布日期的变化移动占位符并随着缓冲区的消耗而调整它们变得很烦人。更糟糕的是，这是一种会造成不必要的错误机会的并发症。
保守地计划发布：不要在你的速度中包括已知-未知；但请在您的发布计划中包含已知-未知。
Sprint 计划不需要
通常当团队使用占位符时，是因为他们想要估计该工作的故事点，以便在冲刺中保留一些容量。在每个 sprint 中放置一个占位符并将其称为 2 点以保留容量是不必要的。
根据产品负责人希望您在上一个冲刺中完成的计划点数量来规划冲刺。如果您使用带有小时估算和基于小时的燃尽图的（子）任务，那么减少您对这些未知事物的能力，但它基于您在之前的冲刺中能够完成的已知知识的计划小时数。
如果您的构建服务器不稳定，或者如果您需要对 VM 服务器进行一些维护，请决定修复它或不修复它。为了以防万一，不要在冲刺中放置占位符。那是糟糕的计划。
不是相对估计
比较相似类型的工作时，相对估计是有效的——known-knowns 和实际用户故事。您不知道您将遇到多少生产支持问题，也不知道解决这些问题需要多长时间。估计这些东西远不如估计已知的知识准确。一般生产支持和其他开销不应显示为冲刺或发布积压中的 估计 项目。让支持活动拖累您的速度。
缺陷和加速怎么办？
一旦存在需要修复的特定问题——一个已知的已知问题，缺陷就应该出现在你的积压工作中。对于高优先级的加速工作也是如此。一旦它成为已知的，就将它添加到你的冲刺中。
但 不要估计缺陷 。让它们成为你速度的拖累。单独跟踪历史缺陷率。您可以在您的冲刺和发布计划中保留容量，而无需为尚未发现的缺陷在占位符上加分。
因完成工作而获得荣誉
如果您的团队正在使用和估算占位符来获得荣誉， 请停止这样做。 如果人们觉得有必要提高他们的速度或获得荣誉，这就是组织的功能障碍。
结论
没有充分的理由在占位符故事上加分。将计划外的东西排除在你的速度数字之外。这导致更简单和更保守的发布计划。