scrum - Scrum：过时的待办事项和外部障碍

Question

我该如何处理在冲刺中期以某种方式变得过时或不必要的冲刺积压项目？我是否将它们标记为已解决？

那些依赖于团队无法控制的外部因素的任务呢？

Answer 1

我假设通过sprint backlog 项目，您的意思是也称为任务，或产品 backlog 项目的细分，正如团队在计划会议期间所做的那样。只需将卡片扔进最近的回收站，或将其标记为已从计算机系统中移除。如果这对您有意义，您可以将它们标记为已解决（如果已解决，则意味着没有剩余工作要做）。

如果这种情况经常发生，那么您的团队可能希望在回顾中提出这一点。这表明团队没有清楚地知道需要做什么——要么是由于计划不充分、对产品待办事项的概念有缺陷，要么可能是需求变化。如果是后者，您可能希望与 PO 一起提出。

关于依赖于外部因素的任务——你应该相应地计划你的工作。将高风险组件与低风险组件分开。让您现有的（和低风险的）模块通过接口与高风险组件交互，并将 API 设计为具有尽可能少的风险表面。

在构建低风险模块时，您应该对高风险模块进行存根（模拟），并且使用依赖注入将为您提供良好的服务，这样您就可以在外部因素可用时轻松地将存根替换为真实的模块。如果外部模块不适合您的接口，请编写一个适配器将您的调用转换为外部模块的 API。

即使在您构建软件之前外部因素是可用的，您也应该考虑执行上述操作，尽管开发存根不如未准备好时那么重要。这样做将保护您的系统免受未来对外部组件的重大更改。

无论哪种方式，您的计划都应该考虑到这一点，并且您应该将问题传达给 PO。他将无法发布任何缺少关键部分的 PBI。

Answer 2

Scrum 指南涵盖了这种可能性：

在 Sprint 期间：

• 随着了解的更多，产品负责人和开发团队之间可能会澄清和重新协商范围。

因此，如果您最终删除了 Sprint Backlog 项目，您的第一个操作是将它们返回到 Product Backlog。您不会将它们标记为“完成”，因为它们不是，这样做会错误地反映速度。

删除 Sprint Backlog 项目后，开发团队可能会觉得他们有能力将其他产品 Backlog 项目带入 Sprint。那是他们的呼唤。

稍后，也许在 Product Backlog Refinement 期间，您可能会决定删除的 Product Backlog Items 不再有用。然后，您可以将它们从产品待办列表中删除，更新包含这些项目的任何产品路线图或发布燃尽图。