关于“结转”的4个误解

在上一篇文章中，我解释了为什么我们需要停止谈论“结转”以及它在Scrum中是如何不存在的。“结转”实际上只是Sprint结束时部分完成的工作。现在我将更深入地与大家分享与这一概念有关的4个常见误解，以及我们如何才能转变为更好地讨论什么才是真正重要的。

关于“结转”的4个常见误解

#1 -产品待办事项清单(pbi)，在Sprint中计划的，但没有完成的，不会在下一个Sprint中自动计划。

环境中可能发生了一些变化，影响了产品待办事项列表的顺序。产品负责人对产品待办事项列表中的内容及其顺序负责。其中的一个我们从Sprint中得到的好处是让能够在每个Sprint中改变方向．如果我们只是假设没有完成的工作转移到下一个Sprint，我们就错过了产品负责人决定下一个正确的工作是什么以便最大化产品的价值的机会。

任何在Sprint中没有完成的pbi都被放回到产品待办事项列表中，它们将被更新、重新估计和重新排序，以反映我们现在所知道的。这有助于确保我们有一个透明的产品待办事项列表。

#2 -在增量中完成部分工作是不允许的。

部分完成的工作不是增量的一部分，因为这会降低进度的透明度，并限制释放价值和获得有意义的反馈的能力。如果Sprint接近尾声的时候有部分完成的工作，那么它需要从增量中删除，以便增量符合已完成的定义。

这是否会造成浪费并可能导致返工?是的。因为这些时间本可以用来创造一些能让我们现在实现价值的东西。当我们回到部分完成的工作时，我们将不得不让自己回到它是什么以及剩下的工作。还有一种情况是，产品已经发生了改变，可能需要重新工作，甚至丢弃以前的工作。

我们需要公开和诚实地面对部分完成的工作如何限制了我们频繁交付有价值的高质量解决方案的能力。

3 .速度并不重要。

是的，我说了。我并不关心你的开发速度，特别是当你试图从部分完成的工作中“获得学分”时。

我经常被问到在计算团队速度时如何“考虑结转”。如果你的速度反映了部分完成的功，那它就毫无意义了。它甚至可能导致进步的透明度降低和质量降低。记住，速度(或任何类型的吞吐量度量)只是您的团队过去将PBIs转化为Sprint中有用的、有价值的增量的能力的指示器。Scrum团队将使用它来帮助他们进行预测。它不是一个团队绩效指标。

重要的是要经常提供有价值的、高质量的解决方案。我也喜欢这样说:在输出结果．

这就导致了第四个误解。

目标不是成为完美的规划者。

Scrum团队并不总是能够“正确”地完成Sprint Backlog。他们可能会提出一个在Sprint中无法实现的Sprint目标。开发人员可能会选择比他们在Sprint中所能完成的更多的pbi。因为即使在Sprint的时间范围内，我们也有复杂性和不可预测性。我们尽我们所能利用我们所知道的。

这就是为什么Sprint Backlog要经常更新，以反映增量出现时的新经验。

解决办法:把注意力转移到更好地讨论什么是重要的

当我们用“结转”这个术语来规范Sprint结束时部分完成的工作时，我们就失去了讨论真正重要的东西的机会。

这里有一些提示可以引导你更好的对话。这是我们获得有意义的透明度和有效的检查和适应的地方，因此团队可以在复杂性中导航并对更改做出响应。

• 我们怎样才能改进我们合作的方式在Sprint中更一致地拥有一个符合“完成”定义的有用的、有价值的增量?我们怎样才能做到这一点而不浪费部分完成的工作呢?
• 为什么我们Sprint这么晚才发现我们不会去完成正在进行的PBIs ?我们怎样才能降低这种情况发生的风险呢?我们如何限制正在进行的工作?
• 如何我们有效地使用了冲刺目标以及我们在Sprint期间对“完成”的定义，以建立专注力，并对我们的进展达成共识?
• 我们的工作效率如何利用每日Scrum了解我们实现Sprint目标的进展情况，并共同规划未来24小时内最有效的合作方式?
• 什么障碍是否存在阻碍我们在Sprint过程中前进或降低进度透明度的因素?我们需要在组织中进行什么样的对话来提高透明度这些障碍的影响？
• 如果有一个持续的模式计划比冲刺完成的还要多？我们认为是什么因素导致了这种情况?这种情况对我们的团队有什么影响?我们想在Sprint计划中尝试什么不同的东西吗?