Sprint回顾——讨论Sprint任务的原因是什么

现在我们的审查会议通常是这样的:

团队正在展示冲刺的目标

团队正在演示Sprint完成了哪些功能

团队会告诉你哪些功能正在进行中，但在Sprint结束时还没有完成。

这与Scrum指南描述的在Sprint评审中发生的事情是一致的。

一个不同之处在于，不符合团队“完成定义”的产品待办事项项不能被……在Sprint评审中提出”。尽管意图是好的，但是由于看到部分完成的工作的涉众可能没有很好地掌握将工作达到完成状态所需要的内容，我发现禁止讨论未完成的工作对于某些上下文来说是过度约束的。

另一个不同之处在于从Scrum团队以及与会的关键涉众的角度讨论环境的变化。了解自上次Sprint评审以来发生了什么变化，可以帮助您对下一步应该是什么做出明智的决定。

在团队演示中，受邀人员会提出关于解决方案的问题，关于下一步可以做什么的想法等等。

总的来说，我们的PO从这部分中获得了很大的价值，因为我们从人群中获得了一些反馈。

在这部分之后，团队之外的利益相关者离开会议，Scrum团队讨论Sprint Backlog。

PO正在检查Jira项目中的任务，并询问一个团队在这里所做的工作。如果任务还没有完成是什么状态。

谈论Sprint Backlog似乎有点奇怪。在Sprint评审的时候，Sprint已经结束。下一个Sprint的Sprint Backlog直到即将到来的Sprint计划会议才会存在。但更奇怪的是，产品负责人需要询问工作状态。Sprint待办事项列表和产品待办事项列表都应该是信息的散热器。涉众应该能够查看待办事项并理解工作的状态，而不需要询问团队。这里可能有一些流程上的改进。

我不确定在Jira中完成这些任务的价值是什么。

就像第一部分一样，我从每个人的意见中获得了明确的价值，这里我们每天都在检查非常相似的任务，没有完成的任务几乎无论如何都要进入下一个Sprint。

Scrum指南指出，在Sprint结束时，任何未完成的产品待办事项项都将进入产品待办事项列表，产品负责人可以在其他产品待办事项列表项中排序，包括在Sprint评审中获得的反馈。

根据我的经验，几乎所有未完成的工作都在产品待办事项列表的顶部结束，因此会被拉到下一个Sprint。这也与从库存中消除浪费是一致的——部分完成的工作是库存的一种形式，所以确保它越早完成和集成越好。

如果需要整个团队来完成工作并理解其当前状态，那么我建议看看您是如何可视化工作状态并加以改进的。产品负责人在订购产品待办事项列表时，不需要从整个团队中抽出时间来了解工作状态。

在我们的Sprint评估中是否遗漏了一些可以给我们带来额外好处的东西?想获取更多关于如何继续开发产品的信息吗?

你可以考虑之前版本的Scrum指南中的一些建议，这些建议可能有助于与关键涉众讨论:

• 前一个Sprint的成功或问题
• 产品待办事项列表的当前产品目标和状态
• 回顾产品的使用情况和产品的潜在用途
• 审查时间线、时间表、预算和预期发布

讨论什么有用取决于你所处的环境。并不是所有事情对每个团队都有意义。

你怎么看会议中处理积压的部分?我应该在这里看什么值呢?我想应该有一些，但我们做错了什么。

这似乎表明Sprint待办事项列表和产品待办事项列表的透明度存在问题。在团队内部(产品负责人是团队的一部分)，工作状态应该有很高的可见性和透明度。

-也许利益相关者也应该参与进来?我们正试图保持与利益相关者的部分作为一个功能相关的，业务的观点。不要谈论那些会让总理感到无聊的技术细节。在Jira中完成任务肯定会深入开发，到目前为止，我认为在利益相关者面前这样做没有任何意义。我们应该改吗?

涉众可能对产品待办事项列表感兴趣，因为这是团队即将进行的工作。确保他们理解当前的订单，以及产品负责人为什么要以这种方式进行订单，这是Sprint评审的一个重要部分。但是，对产品待办事项项的技术分解进行更深入的研究可能不会为关键涉众增加很多价值。

-这部分是关于Sprint Backlog的吗?我们应该在这里寻找什么值?

我会说不，因为在这一点上不应该有Sprint Backlog。任何未完成的工作应返回到产品待办事项列表中，并与其他产品待办事项列表项一起排序。这可以将您的注意力转移到与关键涉众一起的产品待办事项列表上。

这就是我写这篇文章的原因。

我不确定在Jira中完成这些任务的价值是什么。

如果这些任务描述了创建立即可用的质量增量所需的工作，那么根本就不会有任何好处。工作要么已经完成，要么还没有完成，你要么相信开发人员会满足你的要求质量标准的——而且是诚实的——否则就不是。

如果这些“任务”描述范围从产品待办事项列表中分离出来，并被计划到Sprint待办事项列表中不完成到一个完成标准，那么确实有价值的审查他们。Sprint评审的重点是考虑已经完成和尚未完成的工作，并相应地更新产品待办事项列表。

托马斯，伊恩。谢谢你的回答，它们很有价值。

我和我们的订单讨论了这个话题，我希望我们能继续推进这个话题。

我们同意，当利益相关者仍然出席会议时，讨论我们当前的产品目标，我们在路线图上的位置，如果有任何变化，需要实现的优先级将会产生良好的输出。

关于未完成的PBIs和谈论他们。

我们一致认为谈论所有任务没有任何价值。

然而，还有一些未完成的PBIs。其中一些处于“进行中”状态，一些处于“阻止”状态。

目前，PO看到了检查它们的价值，因为可以触发一些要阻止的附加操作，并澄清在进行中的任务中还有什么要做。

然而，正如你所提到的，这可能是任务透明度没有完全发挥作用的迹象。

我可以想象，有了详细的国防部，我们可以立即输出完成了多少任务。

在阻塞任务的注释中，可以显示解除阻塞任务的实际情况。

我说对了吗?

对于未完成的pbi，让我们假设他们被带到新的Sprint，我们想要重新评估他们，讨论是否有一些不可预见的问题。完善它们。什么时候做这件事?在计划吗?我想我们应该已经准备好并清理干净了，但在审查和计划之间没有时间这么做。

你对此有什么看法?

我可以想象，有了详细的国防部，我们可以立即输出完成了多少任务。

我觉得谈论一项任务完成了多少或离完成有多近是没有用的。即使你有详细的“完成”定义，例如，上面有10项任务，满足其中5项并不意味着任务完成了50%。工作并不是均匀地分布在所有需要完成的事情上，以实现“完成”状态。在不同的任务之间，完成完成定义的某个元素所需的努力可能会有所不同。我更喜欢用“完成”或“未完成”来谈论任何工作单元。如果你需要更多的粒度，那么“未开始”、“进行中”和“完成”可以提供更多的见解。其他任何事情都可能导致混乱。

在阻塞任务的注释中，可以显示解除阻塞任务的实际情况。

这应该是在每日例会上更好的讨论。等待Sprint评审来解除阻塞工作的时间太长了。即使您需要与关键涉众交谈以解除工作阻塞，也要在工作阻塞时立即联系他们。

否则，Sprint回顾是一个更好的地方，可以讨论出现的阻碍或阻碍工作的障碍，以及如何及早发现它们并防止它们，这样工作就不会在Sprint过程中受阻。

对于未完成的pbi，让我们假设他们被带到新的Sprint，我们想要重新评估他们，讨论是否有一些不可预见的问题。完善它们。什么时候做这件事?在计划吗?我想我们应该已经准备好并清理干净了，但在审查和计划之间没有时间这么做。

我不认为重新评估工作有价值。然而，如果团队看到了其中的价值，那么他们就可以选择这样做。在Sprint评审和Sprint计划事件之间找到一些时间进行细化是很重要的，即使是在Sprint计划的开始。Sprint评审可能向产品待办事项列表中添加了工作，或者对现有的产品待办事项列表项进行了调整，将不太精细的工作移到更靠近顶部的位置。确保团队有一些时间来完善它，并了解它是否有可能在即将到来的Sprint中进行，这是很重要的。

我很好奇，在Sprint评审结束和Sprint计划开始之间，你没有时间来做任何改进。也许你可以考虑移动其中一个事件，在日历上增加一些空闲时间。

我明白你的意思了。

没错，国防部的一半项目并不意味着整个PBI就完成了一半。

通过这些关于封锁的评论，我认为有行动正在进行，而且很容易看到。现在我认为我们已经采取了行动，但它不是完全透明的，如果有兴趣的人需要问发生了什么。当然，等待审查来解除阻塞任务并采取行动将是完全的灾难。

关于PBIs的重新评估。对此我还没有明确的看法。如果PBI拥有10个SP并且几乎完成了，那么它将对整个sprint的速度和计划产生影响。首先，在之前的Sprint中，它不计入速度。其次，在即将到来的Sprint中，它将被计算为10，但所做的工作可能等于2。

我不确定是否应该陷得这么深。你怎么看?

关于计划前的细化。我想说，在我们的团队中为这部分定义时间框是没有问题的。我在Scrum指南中更多地考虑了这个问题，但可能因为精炼没有被定义为一个事件，所以我们可以在这里将其视为允许的:)

我以前没这么想过。

您从评审中提醒的backlog中可能发生的变化和新的优先级增加了在计划开始时进行此类细化的另一个价值。

我想说的是，Ian在昨天的另一篇帖子中明确了关于故事点的答案。

“速度是做功的速率完成，不部分完成”

关于PBIs的重新评估。对此我还没有明确的看法。如果PBI拥有10个SP并且几乎完成了，那么它将对整个sprint的速度和计划产生影响。首先，在之前的Sprint中，它不计入速度。其次，在即将到来的Sprint中，它将被计算为10，但所做的工作可能等于2。

在我看来，使用故事点来衡量速度是一个错误。正如我在你引用@Ian的同一篇文章中所说的，故事点只是估算。估计是根据您当时掌握的信息在某个时间点所做的猜测。它们对于开发人员确定他们是否觉得有可能在Sprint期间完成大量工作是很有用的。但是，一旦在该项上开始工作，估计就不再相关了，因为您正在发现新的信息。这些信息可以使工作变得更容易或更困难。所以拥有3个故事点的内容所花费的时间可能与拥有13个故事点的内容相同，或者比拥有1个故事点的内容更快完成。使用周期时间和吞吐量等流量指标可以更好地测量速度。

以你的例子为例，你如何知道带有10个故事点的道具在一个Sprint中有8个点，在下一个Sprint中有2个点?会不会是第一场6分，第二场4分?完成一分到底意味着什么?如何衡量呢?

我的观点是你没有完成分数。你完成了工作。正如你所指出的，@Ian的引用是“速度是工作的速度完成，不部分完成”。这不是故事点完成的速度。