我如何处理sprint积压项目，这些项目会以某种方式变得过时或不必要的中间冲刺？我是否将它们标记为已解决？
依赖于团队无法控制的外部因素的任务呢？
答案 0 :(得分：1)
我认为通过 sprint 积压项目，您的意思是所谓的任务，或者产品积压项目的细分，就像团队在规划期间所做的那样会话。只需将卡放入最近的回收站，或将其标记为从计算机化系统中删除。如果这对你有意义，你可以将它们标记为已解决（如果解决了你意味着没有剩下的工作要做）。
如果经常发生这种情况，那么您的团队可能希望在回顾中提出这一点。这表明团队没有清楚地知道需要做什么 - 或者由于计划不充分，对产品积压项目 的概念有缺陷，或可能改变要求。如果是后者，您可能希望提交PO。
关于依赖外部因素的任务 - 您应该相应地规划您的工作。将高风险组件与低风险组件分开。让您现有的（和低风险）模块通过接口与高风险组件进行交互，并设计API以尽可能减少风险。
在构建低风险模块时，您应该存根（模拟）高风险模块，并且使用依赖注入可以很好地服务，这样您就可以轻松地将存根交换为真实模块当外部因素变得可用时。如果外部模块不适合您的界面，请编写adapter以将您的调用转换为外部模块的API。
即使在构建您的软件之前外部因素可用，您也应该考虑执行上述操作，尽管开发存根并不像它没有准备好那样重要。这样做可以保护您的系统免受以后对外部组件的更改。
无论哪种方式，您的计划应该考虑到这一点，您应该将问题告知PO。他将无法释放任何缺少关键部分的PBI。
答案 1 :(得分：1)
Scrum指南涵盖了这种可能性：
Sprint期间：
因此，如果您最终删除Sprint Backlog Items，那么您的第一个操作就是将它们返回到Product Backlog。你没有将它们标记为“完成”，因为它们不是，并且这样做会错误地反映速度。
删除Sprint Backlog Items后，开发团队可能会觉得他们有能力将其他产品Backlog项目带入Sprint。这是他们的号召。
稍后，也许在产品Backlog改进期间，您可能会认为已删除的产品Backlog项目不再有用。然后，您可以从产品Backlog中删除它们，更新包含这些项目的任何Product Roadmaps或Release Burndowns。