是否应该为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?