Scrum回顾不按顺序进行。

我以前经常这么做。一天中发生的所有事情都会让这一天变长。把会议分散在一个晚上的休息时间，有助于缓解背靠背会议带来的疲惫。我建议以“回顾”和“回顾”来结束一天，然后以“计划”开始第二天的工作。通过这种方式，你可以在周四结束一个冲刺，并在周五开始下一个冲刺。

请记住，Scrum指南提供的唯一指导是，当前一个Sprint结束时，Sprint开始，评审和回顾是结束Sprint的事件，因为它们的目的是反思Sprint，以改善产品待办事项列表和团队合作的能力。

我建议我们可以。我们可以在第二天做冲刺回溯，然后做冲刺计划，然后在下午一点开始冲刺计划。

为什么团队提出了不同的安排?

如果在回顾期间，团队决定改变Sprint计划的某些内容，而您在回顾之前进行计划，那么您已经错过了一个机会。

在一天内进行Sprint评审、Sprint回顾和Sprint计划不仅会占用大量时间，而且还会让团队精疲力竭。我还发现它会缩短事件，导致团队试图过多地压缩事件，而无法获得预期的结果。也许对于一个星期的冲刺，你可以适应所有的事情，但是对于更长的冲刺，一天要适应很多事情。

很少有不建议在两天内进行活动的情况。我曾与一些团队合作，他们将活动分成回顾/回顾和计划，以及回顾和回顾/计划。我没有注意到任何巨大的差异，但回顾/回顾与计划在某一天似乎感觉更自然，因为这一天是“结束”或“结束”一个Sprint，而另一天是“开始”下一个Sprint。

我还想说，你需要在下一个Sprint计划之前进行Sprint回顾，这是绝对正确的。不仅Scrum指南的最新修订要求这个顺序，而且如果不从之前的Sprint中学习，就无法有效地制定计划。即使你没有正式地把一个改进项目作为Sprint Backlog的一部分(这已经不再需要了)，你也不能解释过程改进的影响，完成定义的改变，或者对团队工作方式的任何其他调整。您要么需要重新考虑您的计划(导致浪费时间和精力)，要么将改进推迟到下一个Sprint。两者都不可取。

我知道团队想把回顾会议挪到第二天，也就是Sprint计划完成之后。我说对了吗?

我不会阻止团队的尝试——最坏的结果会是什么?我鼓励实验，我坚信团队协议是很重要的。

然而，在达成任何团队协议之前(比如是否实践Scrum，他们的会议顺序等等)，我首先会:

——弄清楚这个提议的机会是否得到了团队所有成员的广泛支持，或者也许只有一两个人对它充满热情。

注意当前的情况(当前的协议)，并让团队写下他们对将会发生的事情的预测。我的意思是，由于对协议的调整，可能会出现什么“好”结果，以及可能会出现什么意想不到的后果或“坏”结果。它可以帮助团队了解变更是否有益。

我怀疑，在使用新的事件安排的几个sprint之后，团队将有一个新的视角，可能会撤销更改，或者适应并尝试其他东西。

我很好奇为什么团队似乎想推迟Sprint回顾，而不是Sprint计划。

会不会是他们不认为他们被允许推迟Sprint计划，但是如果他们推迟对其有效性的持续改进，在更广泛的组织中不会有反对意见?

Sprint评审和回顾会议结束于每个Sprint的末尾，因此，我建议将它们安排在Sprint的最后一天。然后我会在第二天制定你的Sprint计划。我不建议把他们都安排在同一天，因为这会让团队非常疲惫。我个人喜欢将回顾会议作为冲刺的最后一次会议，这样团队就可以反思整个冲刺，包括所有的scrum仪式，并真正思考我们如何在下一个冲刺中改进。让他们休息一晚是很好的，这样他们在第二天进行冲刺计划时就会更有精神;此外，你还可以将从“复古”中学到的东西融入到下一个冲刺中。我们公司就是这么做的，效果很好。