假设您正在编写一段遗留代码，该代码是在您的公司开始使用像 Scrum 这样的敏捷方法之前编写的。
现在假设您在该领域发现了一个需要修复的错误，并且从未编写过该功能的故事。团队中的每个人都知道那个特别的功能是什么以及它应该如何表现，但只是没有与之相关的故事。
现在，在当前的 sprint 中，您将处理该缺陷，因为营销和支持已经厌倦了处理该问题。
您是否创建了一个回顾该缺陷的故事？您是否将缺陷重新标记为故事并修改格式以使其看起来像故事？如果您不创建故事，您是否会因缺陷而获得积分？如果您确实创建了一个故事，您是否会因修复缺陷而获得积分（通过故事的积分）？
处理这种情况的最佳方法是什么？
更新：假设安装过程突然开始在 Windows 7 64 位系统上蓝屏，并且一直要求应用程序安装在所有 Windows 平台上。新问题可能是由于 Service Pack 1 或类似的东西而出现的。
您是否创建了一个回顾该缺陷的故事？
是的。它也值得回顾，以确保每个人都同意这个故事。
如果它是一个没有错误但令人讨厌的界面，那么您实际上是在修改工作流程，并且确实需要将其作为一个适当的故事来纪念。
如果涉及到错误，那么单元测试应该已经找到了错误（但没有）。这似乎不是您的情况，但不完整的单元测试通常不会发现错误。扩展单元测试（在修复故事之后）也非常重要。
您是否将缺陷重新标记为故事并修改格式以使其看起来像故事？
并不真地。缺陷只是一个缺陷，无论是否有故事。
缺陷消失。故事没有。
如果您确实创建了一个故事，您是否会因修复缺陷而获得积分（通过故事的积分）？
为什么不？
编辑. 故事点问题很困难。理想情况下，这些点会跟踪完成的工作和创造的价值。故事==努力==积分。但是在处理重用、发布和返工时会出现问题。
你有几个不相关的问题：努力、质量和价值。这些点可以跟踪其中之一。它无法跟踪其他任何一个。
如果您认为速度应该反映努力，那么您不能因为错误或需求更改而扣分。它不跟踪创造的价值，也不能用于此目的。
如果您认为速度应该跟踪价值，那么您必须拿走分数。它不跟踪工作量，因为工作已经完成，但它的功劳被删除了。
返工很艰难。错误和需求更改是一回事，它们是返工。你有各种各样的候选人。
实现错误的“简单”错误，但故事是“正确的”。理想情况下，这不计入速度。对？
“不完整的故事”错误，实现正确，但故事省略了一些关键（和技术）细节。唔。谁该受责备？谁的速度测量应该为此受到惩罚？
我们在测量什么？努力？工作完成了。价值？没有创造价值。
“错误的故事”错误，实现是正确的，但故事从一开始就是一个坏主意，没有人抓住它。这可以称为“说谎的用户场景”。它发生了。理想情况下，这计入速度。用户撒谎。但是，您如何将其与任何其他返工区分开来？“规矩”是什么？
“改变故事”错误，实施正确，故事正确。但整体背景发生了变化，故事也需要改变。这只是“增强”或“适应”，就像新作品一样。当然，这不是全力以赴的工作，是吗？这可能只是对现有代码的调整，因此您不想用所创造的全部价值来过度奖励它。
我们在测量什么？努力？一些已经完成，但不多。价值？创造了价值。
底线。积分是一种政治武器，并不能衡量太多。努力或价值，但不能两者兼而有之。而且不好。
在 Scrum 中，只有用户故事。与功能一样，缺陷是产品所有者要求对系统进行一些更改以提供新的业务价值的请求。
如果在发布后报告了一个缺陷，那应该作为一个新的故事进入积压工作。跟踪一些关于缺陷细节的注释（谁报告它，环境等）是非常好的。作为一个故事，团队应该在 PO 选择 sprint 之前对其进行估计。
如果在 sprint 期间报告了一个缺陷，并且 PO（和团队）的决定是它是低级别的并且不会导致故事失败，那么该缺陷会作为新的故事移回积压工作以供将来考虑。
在我的团队中，我们经常发现基于缺陷的用户故事的大小为 0.5-1 个百分点——并非总是如此，但通常足够了。我们发现，选择一套 0.5-1 点的故事可能会给 sprint 的速度带来一些噪音，因为每个估计的故事都会产生一些估计误差。如果像这样非常小，我们会将几个故事聚集在一起，并创建一个故事集群估计。我们发现，有时由于各种修复的重叠，估计值会有所不同 - (5) 1 分的故事可能总计为集群的 3 分。
还有更多方法可以做到这一点。我通常创建原始故事和错误。我给最初的 0 故事点是因为它没有剩余的工作——剩余的工作应该始终是故事点的主要焦点——而不是“团队分数”。
恕我直言，您不会“得分”故事点。你所做的就是在冲刺期间吃掉它们。如果你是一个好孩子并且吃尽了所有你可以吃甜点（更多的积压项目）。如果没有，那么你在下一个冲刺中吃剩菜:-)
更新： 你也可以只写缺陷，因为你真的没有在 sprint 中实现原始故事（或在当前项目中）
我想建议保持简单。我看不出故事和修复缺陷之间有真正的、有价值的区别。他们都改变了系统；如果它们会在完成后为用户带来一些价值，那么它们是否会为客户带来价值；两者都有成本；它们都比某些故事（和缺陷）更重要，但比其他故事更重要。
所以，如果它像鸭子一样走路，像鸭子一样嘎嘎叫……我称之为用户故事。
将其视为任何故事（您可以将其写成“为了能够保存我的高分，作为火狐用户，我希望修复 JIRA 234”）。
这样，PO 可以决定何时处理错误，就像任何其他任务一样。
希望这会有所帮助，阿萨夫。
TLDR：
需要一个故事来捕获需求（就像您捕获任何需求一样）以及您想要修复的缺陷。需要这个故事来编写测试，以便您知道何时修复了缺陷。
长版：
你有缺陷。
你怎么知道哪一块功能有缺陷？
有缺陷的功能必须记录为需求或在某处有一些规范；无论是在纸上，在电子邮件中还是在某人的脑海中。
所以恕我直言，将它作为一个故事来捕捉是有道理的。
为什么 ？
因为你需要一个故事，所以你所做的一切都应该反对一个故事。你怎么知道你什么时候修复了这个缺陷？
唯一知道的方法是通过某种测试。您如何知道测试何时通过？
一个缺陷会告诉你一个测试失败的标准，它不会告诉你什么时候应该通过。注意：如果您碰巧在错误报告中描述了应该发生的情况，那么该信息可以作为故事的[一部分] 被捕获，并被捕获作为测试的通过标准。
因此，要知道您的测试是否已通过，要知道某项功能不再有缺陷，就需要对如何通过该测试有一个要求，您应该将该要求捕获为一个故事，就像您捕获所有其他需求一样。