在把一个产品从传统方法向敏捷方法的迁移过程中，团队通常带着一大堆bug前行。这通常是缺泛持续的高质量要求的自然结果。导入敏捷后不用多久，很多团队（及他们的产品负责人）会决定激进去清除这些Bug的backlog。 通常的做这件事的方法都是在每个Sprint中计划修复掉X个bug，或者是每个Sprint中计划花Y小时用在修复bug上。有时团队会为这样的活动写一个用户故事如“作为一个用户，我希望至少有15个bug被修复”或者“作为一个用户，我希望你这个Sprint中花大约50个小时去修复bug，使得应用系统逐渐的变得质量更高”。即使团队并没有明确的写一个这样的用户故事，他们也通常会在他们的任务板中加这么一行，以便于bug修复的工作是可见并且可以跟踪的。
在这样的情况中，一个通常的问题就是关于团队是否应该为这些修复遗留的bug的工作分配故事点数。
如果团队不为这些工作安排故事点(值), 团队速率就只能显示团队在每个sprint中的“新的工作”的工作量。这样做的好处是能够清楚的看到团队这是去修复bug会比当时发现时立即修复会更慢一点。
另一方面，如果团队为修复bug的工作安排故事点，团队速率能代表团队的真实的完成工作的容量。
我通常的推荐是为bug修复的工作安排故事点。这样可以。This really achieves the best of both worlds. 我们能看到团队能完成的真实的工作是多少，同时也能通过历史数据看出每个Sprint中我们花了多少工作在bug修复中。 了解这些对于团队和他们的产品负责人都有很大的帮助。举个例子，假设当产品负责人考虑在接下来的六个Sprint中暂停bug修复的工作，以在发布中增加一个有价值的新功能。在这种情形下，如果我们知道这个团队的全部历史平均速率是25，每个Sprint中花5个点做bug修复，我们马上 就知道了接下来6个Sprint暂停bug修复后我们能有30个点可用于新功能。
来自Mick Cohn博客
原文地址：http://blog.mountaingoatsoftware.com/should-story-points-be-assigned-to-a-bug-fixing-story
