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