假设你正在处理一段遗留代码，该代码是在你的公司开始使用Scrum等敏捷方法之前编写的。
现在让我们假设你在这个领域发现了一个需要修复的bug，并且从来没有关于这个特性的报道。团队中的每个人都知道特定的功能是什么以及它应该如何表现，但却没有与之相关的故事。
现在，在当前的冲刺中，你要解决这个缺陷，因为营销&;支持者们厌倦了处理这个问题。
您是否在回顾中为要链接到的缺陷创建了一个故事?您是否将您的缺陷重新标记为一个故事，并修改格式使其看起来像一个故事?如果你没有创建一个故事，你会因为这个缺陷得到分数吗?如果您确实创建了一个故事，您是否获得修复缺陷的点数(通过故事的点数)?
处理这种情况的最好方法是什么?更新:假设在Windows 7 64位的系统上，安装过程突然开始蓝屏，并且一直要求应用程序安装在所有Windows平台上。新问题可能是因为服务包1或类似的东西而出现的。
您是否在回顾中为要链接到的缺陷创建了一个故事?
是的。它也值得回顾，以确保每个人都同意这个故事。
如果它是一个没有bug，但令人讨厌的界面，那么你真的在修改工作流，它确实需要作为一个适当的故事被记住。
如果涉及到bug，那么应该有单元测试发现bug(但没有)。这似乎不是您的情况，但是不完整的单元测试找不到bug是很常见的。扩展单元测试(在修复故事之后)也是非常重要的。
您是否将您的缺陷重新标记为一个故事，并修改格式使其看起来像一个故事?
没有。不管有没有故事，缺陷就是缺陷。
缺陷消失。故事没有。
如果您确实创建了一个故事，您是否获得修复缺陷的点数(通过故事的点数)?
为什么不呢?
编辑。故事点问题很困难。理想情况下，积分跟踪完成的工作和创造的价值。故事=努力=分数。但是在处理重用、发布和返工时出现了问题。
你有几个不相关的问题:努力、质量和价值。这些点可以追踪其中一个。它不能跟踪其他任何一个。
如果您认为速度应该反映工作量，那么您就不能因为bug或需求变化而扣分。它不跟踪所创建的值，并且不能用于此。
如果你认为速度应该跟踪值，那么你必须去掉点。它不跟踪工作，因为工作已经完成了，但是它的信用被删除了。
返工很困难。bug和需求变更是一回事，它们是返工。你有各种各样的候选人。
-
"简单"的错误，其中实现是错误的，但故事是"正确的"。理想情况下，这并不计入速度。对吧?
-
"不完整的故事"漏洞，即执行是正确的，但故事遗漏了一些关键(和技术)细节。嗯。这是谁的错?谁的速度测量应该为此受到惩罚?
我们测量的是什么?努力呢?功已完成。价值吗?
-
"错误的故事"bug，即实现是正确的，但故事从一开始就是一个糟糕的想法，并且没有人发现它。这可以被称为"说谎的用户场景"。它会发生。理想情况下，这可以计入速度。用户撒谎了。但是，您如何将其与其他返工区分开来呢?"规则"是什么?
-
"Changed story"bug，其中实现是正确的，并且故事是正确的。但整体背景改变了，故事也需要改变。这只是"增强"或"适应"，就像新的工作一样。当然，这不是全心投入的工作，不是吗?这可能只是对现有代码的一个调整，所以你不想用创建的完整值来过度奖励它。
我们测量的是什么?努力呢?一些被完成了，但不多。价值吗?
。分数是一种政治武器，没有多大意义。要么努力，要么价值，但不能两者兼而有之。
在Scrum中，只有用户故事。缺陷，像特性一样，是产品所有者提出的对系统进行某些更改以交付新的业务价值的请求。
如果在发布后报告了一个缺陷，那么它应该作为一个新的描述进入到backlog中。跟踪一些关于缺陷细节的注释(谁报告了它，环境等等)是非常好的。作为一个故事，在PO选择sprint之前，团队应该对其进行评估。
如果在sprint期间报告了一个缺陷，并且PO(和团队)的决定是它是低级的，并且不会导致故事失败，那么该缺陷将作为一个新的故事移回待办事项中，以供将来考虑。
在我的团队中，我们经常发现基于缺陷的用户故事出现在0.5-1点的大小上——不总是这样，但经常足够了。我们发现，选择一组0.5-1点的故事可能会给sprint的速度带来一些干扰，因为每个估计的故事都会产生一些估计误差。我们将把几个故事聚在一起，如果像这样很小的话，并创建一个故事聚类估计。我们发现，有时由于各种修复的重叠，估计是不同的——(5)1分的故事可能在集群中总共达到3分。
有更多的方法。我通常会创造最初的故事和bug。我给出最初的0个故事点，因为没有剩下的工作——剩下的工作应该是故事点的主要关注点——而不是"团队得分"。
恕我直言，你并没有给故事点"打分"。你要做的就是在冲刺时吃掉它们。如果你是一个好孩子，把它吃完，你可以吃甜点(更多的待办事项)。如果没有，那么你在下一次冲刺中吃剩菜:-)
更新:您也可以只写缺陷，因为您确实没有在sprint中实现最初的故事(或者在当前的项目中)
我想建议保持简单。我看不出故事和缺陷修复之间有什么真正有价值的区别。两者都改变了系统;如果它们能够在完成后为用户或客户带来一些价值;两者都有成本;两者都比一些故事(和缺陷)更重要，而比其他故事更重要。
所以，如果它像鸭子一样走路，像鸭子一样嘎嘎叫…我把它叫做用户故事。
把它当作任何故事(你可以把它写成"为了能够保存我的高分，作为一个火狐用户，我希望JIRA 234被修复")。
这样PO就可以决定什么时候处理bug，就像处理其他任务一样。
希望这有帮助，艾瑟夫巴德。
TLDR:
需要一个故事来捕获您想要修复的缺陷的需求(就像您捕获任何需求一样)。这个故事是编写一个测试所需要的，这样你就知道什么时候缺陷被修复了。
长版:
你有缺陷。
你怎么知道哪个功能有缺陷?
有缺陷的功能必须作为需求文档化，或者在某处有一些规范;不管是写在纸上、电子邮件里还是某人的脑海里。
所以我认为把它作为一个故事是有意义的。
为什么?
因为你需要一个故事，所以你所做的一切都应该与一个故事相抵触。您如何知道何时已经修复了这个缺陷?
唯一的方法是通过某种测试来知道。你怎么知道考试通过了?
一个缺陷会告诉你给你一个测试失败的标准，它不会告诉你什么时候应该通过。注意:如果您碰巧在bug报告中有一个应该发生什么的描述，那么该信息可以作为故事的[一部分]被捕获，并作为测试的通过标准被捕获。
因此，要知道您的测试是否通过了，要知道某个功能不再有缺陷，就需要有一个测试将如何通过的需求，您应该捕获该需求作为一个Story，就像捕获所有其他需求一样。