是否应该为 Bug 分配故事点数？

在将一个项目迁移至 Scrum 时，经常会面对一份 Scrum 时代之前的缺陷列表。如何最好地处理这份缺陷列表呢？Mike Cohn 推荐向以前的缺陷分配故事点数，并用标准的 Scrum 流程在每个 Sprint 对他们排序：

我通常推荐对缺陷修复分配故事点数。…那样，我们不仅能看到团队真正能完成多少工作，也能通过历史数据看出每个 Sprint 中花在修复缺陷上的工作量。知道这些对团队和产品负责人都很有用。比如，假想一种情况，产品负责人考虑在接下来的 6 个 Sprint 中暂停缺陷修复，为的是在下一次发布中增加一个有用的新功能。如果我们知道团队的历史平均速率是 25，但是其中 5 点花在缺陷修复上，那我们就可以知道暂停下 6 个 Sprint 的缺陷修复工作可以增加 30（6*5）个点数的新功能。

除了 Mike Cohn 推荐的 Sprint 排序策略外，Charles Bradley 想要有更多的选择，让开发团队在 Sprint 之内修改缺陷。

…PO 可以排序缺陷的优先级使他们出现在 Sprint 中，开发团队也可以任意挑选他们认为需要修改的缺陷（不管缺陷是否在 Backlog 中），并且把它列为 Sprint 中的一个任务（他们不会为此得到速率中的点数，无论缺陷是否在 Backlog 中）。只有开发团队可以决定在一个 Sprint 中做多少产品 Backlog 条目，所以，如果他们决定花 Sprint 中 50% 的时间来修复 PO 没有排序的缺陷，那就只能这样。但这会清晰可见，因为他们的速率会减慢。

Jack Milunsky 在处理遗留缺陷和当前 Sprint 产生的缺陷之间做了一个重要的区分：

如果要向缺陷分配故事点数，那只能分配给遗留缺陷。这对 PO 绝对有好处，特别是质量。在 Sprint 中发现和解决的缺陷不应该被分配故事点数，因为这会影响速率，造成团队工作更快的假象。

如果是在 Scrum 实施中产生的，由于一些原因在 Sprint 验收中漏掉的缺陷，我们应该分配故事点数嘛？也就是说，在之前 Sprint 认为“完成”的用户故事中发现的缺陷应该怎么办？Ron Jeffries写到：

如果由于某些原因一个故事已经完成，然后发现了一个缺陷，而那个故事已经被记录在速率中，那速率是虚高的。我们应该做什么？一种做法是从我们的进度条中去掉那些量，当缺陷被修复后再把那些量加回去。这可能更准确，但却不必要。 我们所要做的，只是计算下次做完的故事。花在修复缺陷的时间不算在内。我们的进度线从现在开始减少了一个故事。这条线虚高了一阵子，但现在又恢复了。

注意，修复错误的时间可能比构建一个出错故事的时间要短，或者长。无论如何，正确 完成故事所必须的时间，以及完成故事的数目，对那个故事来说会回归平衡。不需要估计，不需要解释为什么我们应该如对待好事般对待一个明显的浪费。

查看英文原文： Should You Assign Story Points To Bugs?