您提到的方法也由 Mike Cohn 在是否应该将故事点分配给敏捷缺陷故事？，他写道：
有时团队会为此活动编写用户故事，例如：“作为用户，我希望修复至少 15 个错误”或者，“作为用户，我希望您在这个 sprint 中花费大约 50 个小时来修复错误，以便应用程序逐渐更高品质。” 即使是没有明确编写此类用户故事的团队，通常也会在其任务板上包含一行，以使敏捷缺陷和错误修复可见并进行跟踪。
您目前有一个称为维护缓冲区的故事，您可以在其中分配一些时间来解决故障单，这与 Mike Cohn 的文章中所述的内容相似，他建议将点数分配给修复敏捷缺陷的错误。
也可能有其他选择，比如
遇到紧急情况/修补程序时该怎么办？
您需要评估修复该紧急错误所需的重要性和工作量。由产品负责人决定团队是否放弃所有内容并开始处理修补程序。原因是客户永远是第一位的，如果交付的产品没有提供预期价值，那么为不完整的产品添加更多功能是没有用的。没有任何框架/方法可以阻止您处理特殊情况或要求您忽略关键问题。因此，当前的 sprint 可以取消，或者如果热修复可以由团队的一个（或一些）成员处理，则当前 sprint 中的功能或错误可以与紧急错误修复交换。
用生产支持和 Scrum的 Geoff Watts 的话来说：
如果问题是真正的紧急情况，产品负责人应该有权打“应急牌”，只要他知道这样做的成本——没有完成我们计划的项目，并可能危及冲刺目标。
产品负责人可以行使以下 3 个选项中的任何一个：
简而言之，我会将错误作为产品待办事项 (PBI) 提出，并将它们与产品待办事项中的其他 PBI 进行优先级排序。这样，您始终可以确保首先完成最重要的事情。
Scrum 的不成文合同的一部分是业务同意不打断开发团队。这部分是他们可以提高性能的方式。
如果你得到一张不能在 Sprint 期间等待的热门/紧急通知单，你需要说服产品负责人，然后他们将与开发团队协商引入热门项目的最佳方式。
但是，这需要是一个例外，而不是规则。如果，正如您所暗示的那样，您需要修复很多错误，我会很想与使用 KanBan 而不是 Scrum 的单独团队一起运行维护/缺陷修复。
我同意你的观点，这不是一种很好的敏捷做事方式！要问的问题是 - 您的真正目标是计划维护时间还是确保您的团队在用户故事和缺陷方面得到最佳利用，同时持续产出高质量的代码，包括缺陷修复？
我会比 Derek 的建议更进一步——同时使用看板和 Scrum——Scrumban 越来越流行！由于您已经说过在任何 sprint 中可能有 0 到 5 个缺陷，显然您的“故障需求”是可变的，对“维护工程师”能力的需求也是如此。当有 0 个或 1 个或 2 个缺陷时，他们会怎么做？我认为它们也有助于“价值需求”——新的用户故事。
这就是看板大放异彩的地方。虽然您的团队需要对看板的实际设计进行分析，但您可以从一个简单的 2 泳道板开始，它反映了您当前的工作流程。一个简单的例子如下所示 -
在这里，您的所有工程师都可以在任一车道上工作。随着工作的流入，取决于谁可以自由地接手 - 并且可以接手 - 他们会拉动工作并继续工作。您仍然在 Staging 为 sprint 批量处理 - 并一次性部署该批次。
或者，您可能有完全独立的用户故事和缺陷通道 -
同样，您的所有工程师都在两个通道中处理项目。但是，一旦缺陷修复被客户修复并接受（如果适用），您就可以灵活地部署它们。根据您的价值需求，您将继续遵循与现在相同的流程，并在每个 sprint 完成时进行部署。
这两种方法的优点是 -
当然，这只是基于基本分析。如果您不熟悉看板或 Scrumban，您应该阅读 David Anderson (Kanban) 的书籍和 Corey Ladas (Scrumban) 以及 Yuval Yeret、Jim Benson、Masa Maeda 等其他人的论文，并做好准备。您也可以通过 www.swiftkanban.com 与我们联系，我们当然也可以提供帮助。
希望这可以帮助！