将PBI从sprint backlog转移到sprint中期的产品backlog

(意见)

是的——尽快将订单纳入对话。即使订单由于某种原因无法使用，backlog也应该保持可见，并在列表底部显示某些项目确实已“订购”。

我会把项目留在Sprint backlog本身。允许团队在回顾中讨论这个问题。也就是说，为什么我们不能得到这些东西，即使我们已经计划好了?等。

此外，人们永远不知道是否存在其他sprint backlog项目的障碍，从而允许开发团队处理他们认为不可能完成的事情。

我也曾与一些团队合作过，他们在Sprint计划之后很快就把事情踢出去了。例如——两周冲刺的第二天。这鼓励开发团队尽快完成计划并尽早协商范围(如果可能的话)。

当有大量工作出现或团队承担了太多工作时，这是一种模式的指示，而不是例外。善于观察的ScrumMaster应该尝试通过让事情可见并反馈给团队来弥合差距。这种情况最终应该成为一个例外，而不是常态。

(/意见)

>……没有时间完成优先级最低的PBI
>冲刺，他们是否应该与产品负责人讨论，如果
>如果发现它不会危及冲刺目标，那就移动它
>立即回到产品待办事项列表?

这是一个合理的设想。然而，重要的是要在优先级(在顺序意义上)和价值之间划出清晰的界限。

Sprint Backlog完全由开发团队拥有，并且由他们决定如何以及何时执行工作以满足Sprint目标。除非他们已经与订单安排在Sprint期间交付增量的元素，否则在Sprint期间给予每个PBI行动的优先级将因此取决于他们。

这使得Sprint Backlog中优先级最低的PBI完全有可能成为对PO最有价值的PBI之一。例如，Sprint中最有价值的PBI可能在技术上依赖于其他PBI。开发团队可能会合理地计划首先执行依赖项，因此这些项目将在Sprint Backlog中被赋予更高的优先级。

如果团队发现他们不可能在Sprint中交付“最低优先级”的PBI，那么做什么决定将因此取决于它的相关值。如果PBI对Sprint目标至关重要，那么PO可能决定取消Sprint。或者，可以重新规划，这样仍然可以实现目标。在涉及约定价值交付的所有情况下，必须与产品所有人协商。

我会把这些项目留在Sprint backlog中。

我倾向于将它们作为未完成的工作返回到产品待办事项列表中，并将Sprint待办事项列表作为团队真正的当前计划来维护。

在规模上，这将潜在地允许从相同的产品待办事项列表中抽取的任何其他团队来处理项目。

我认为sprint backlog应该保持不变，直到结束，未完成的项目将在sprint评审中声明。
这样我就不能改变速度数据，并有数据在不同的sprint之间进行可能的比较，特别是分析为什么在sprint回顾中有些项目没有完成。在sprint结束时，将稍后处理sprint中的项目，或者可能同时经历了业务价值的降低，然后按较低的优先级排序。

真正的问题是为什么团队意识到开始冲刺就不能完成工作?没有完成的项目可能是无法寻址的，所以它们在故事点中的价值太高了?这是对sprint的回顾分析。

在sprint的末尾，必须完成增量。

如果低优先级的项目不影响“完成”的定义，那么这些项目可以回到PB或下一个sprint。

然而，我会将这些项目保留在sprint backlog中，因为几天之后，开发团队可能会发现他们实际上也可以在当前的sprint中实现这些项目。

无论决定是什么，如果sprint backlog中的某些项目在当前的sprint中没有得到解决，那么应该咨询采购订单，因为他应该同意“完成”不受影响。