缺陷在Scrum中应该有故事点吗？

Question

据我所知，我们使用故事点来衡量Scrum中故事的复杂性。

但是缺陷呢？缺陷应该有故事点吗？如果是这样，那么完成这些要点意味着什么呢?考虑到缺陷不像一个故事那样具有商业价值？我们是否应该有一些不同于故事点的东西，例如，缺陷点？

Answer 1

我认为，缺陷代表了早期尚未充分完成的特性。因此，缺陷的修复并没有给出故事的要点。

如果你把故事点应用到缺陷上，你的刻录率看上去很棒“我们完成了20个故事点的功能--但是，其中10个是错误修正的，所以你的实际进度只有10个。”

现在，我并不主张在发现之后立即修复sprint中的每个bug。有些bug没那么重要。但是不要“完成”一个5点的特性，那么下面的sprint会对它再做5点错误修正--它掩盖了错误的估计、糟糕的编码或两者兼而有之。

Answer 2

我曾在几个scrum团队中讨论过这个问题，但最终得出的结论是，缺陷应该像故事一样被指出。原因在于我们使用故事点的目的--通过测量每个sprint完成的故事点的数量，我们可以得到一个粗略的度量团队的能力，团队在一个sprint中可以完成多少工作。

如果一个缺陷足够重要，以至于它会将开发资源从其他故事中拿走，那么它就应该被指向并显示在您的团队的sprint能力中。我总是发现，一旦测试工作进入到讨论中(通常包括编写遗漏的单元/集成测试)，它最终都会成为足够重要的工作来指出。如果这个bug非常小，并且不需要真正的测试工作，那么您总是可以给它零分。

Answer 3

我的团队将故事点放在故事完成后的sprint之后发现的任何缺陷上。如果在故事正在开发的sprint过程中发现了缺陷，我们将考虑那些接受错误，并将其作为故事原始估计的一部分。