Scrum事件时间盒如何让你的团队更有效率

每个Scrum事件都有一个最大允许的执行时间段，称为时间框。当我告诉别人Sprint计划活动的时间是8小时时，我通常会得到震惊的表情。“八小时!他们会说:“太可怕了!”

关于在Scrum中应用时间框，似乎存在一个误解。

虽然Scrum事件有一个最长的时间，他们没有最少的时间．一旦团队涵盖了所需内容，活动就结束了。Scrum时间框的存在是为了防止团队花费太多的时间来计划和审查，而不是做Sprint的工作。他们让你的团队更有效率。

我只参加过一次花了整整8个小时的Sprint计划活动。大多数都比较矮。八个小时后，团队仍然并没有完成他们希望完成的所有事情!其中一个开发人员问我们是否应该在第二天继续讨论。答案是否定的，因为团队已经到达了时间框。

我记得当团队的其他成员听说第二天我们将不再继续Sprint Planning时，他们松了一口气。相反，在我们马拉松式的Sprint计划活动之后的第二天，Scrum团队刚刚开始工作，并且在Sprint期间出现了Sprint Backlog的剩余部分。

让我们看看所有的事件时间框，以及它们如何使Scrum团队更有效。

Scrum事件时间盒

下表显示了Scrum中的五个事件及其时间框。

冲刺——一个月或更短时间

Scrum中的第一个事件是Sprint本身。Sprint不是会议;它是所有其他事件的容器。Sprint有一个月的时间框，因为在复杂的环境中，人们不可能在任何细节层面上制定超过一个月的计划。此外，短时间范围缩小了反馈循环，因此Scrum团队至少每月与涉众一起审查一次增量，并就下一步该做什么进行协作。更短的时间框的好处是将Sprint的投资限制在一个月的时间和资源上。

Scrum团队对Sprint持续时间的误解与风险有关。大多数人认为在风险更大的环境中，冲刺应该更长。事实恰恰相反。当环境中可能发生意外变化时，更短的sprint意味着团队可以频繁地重新计划以考虑这些变化。例如，如果您的涉众经常要求更改，或者您的技术是未知的或有风险的，那么较短的Sprint可以让您更快地对这些不确定性做出响应。

Sprint计划(8小时或更少)

Scrum中的下一个事件是Sprint计划事件，Scrum团队为即将到来的Sprint计划工作。如上所述，此事件限制在8小时内，因为超过8小时就是浪费时间。Scrum是基于经验主义(基于已知的东西做决定)和精益思维(减少浪费，专注于本质)。超过8小时的冲刺计划就是不专注于必需品!

每日Scrum(15分钟)

接下来是每日Scrum，这是一个简短的15分钟的每日活动，供开发人员协作。如果开发人员发现了需要进一步讨论的障碍，他们可以在每日Scrum之后进行讨论，并且只包括那些需要出席的人。同样，把这个活动的时间限制在15分钟内可以避免浪费。

Sprint评审(4小时或更少)

在Sprint临近结束时，Scrum团队及其涉众举行Sprint评审，讨论团队在增量中交付的内容，并决定下一步要做什么。Sprint评审有四个小时的时间框。

Sprint回顾(3小时或更少)

Sprint临近结束时，Scrum团队及其涉众聚集在一起进行Sprint回顾，以识别和消除低效率。Sprint回顾的时间是3个小时，在这段时间里，Scrum团队确定了至少一个他们可以改进的地方，以改进他们的过程、他们一起工作的方式，或者他们的完成定义。

一周冲刺的典型日历

乍一看，似乎是这样团队将召开许多会议以适应Scrum活动。但当你意识到事件发生在Sprint过程中时，情况就不同了;它们不会在一天内全部发生。

让我们看看一个典型的一周冲刺。

日历将从一个小时的冲刺计划开始。现在，虽然Sprint计划事件的时间框是8小时，但更短的Sprint通常需要更少的时间。根据我的经验，一个典型的为期一周的Sprint通常有一个小时的Sprint计划事件，假设团队在Sprint期间很好地完善了产品待办事项列表。

在Sprint期间，团队将进行每日Scrum，每天花费15分钟。让我们假设Scrum团队每天有15分钟的工作时间。这意味着他们将在每个Sprint中花费1个小时，假设他们在Sprint的第一天没有这样的时间。

在Sprint结束时，Scrum团队将进行Sprint评审。虽然这个项目的时间是4小时，但更短的sprint需要更少的时间。让我们假设一个小时的Sprint评审，这对于我们场景中的团队来说是合理的。

Sprint以Sprint回顾结束。Scrum中的最后一个事件有三个小时的时间框，但是对于一个典型的一周Sprint，我们可以在Sprint回顾中假设每个Sprint是半个小时。

总的来说，您会发现一个典型的团队进行为期一周的Sprint时，在Scrum事件上只花了4.5小时。如果我们增加一个小时的改进会议(这在Scrum中不是一个事件，但是一种常见的实践)，那么每周就只有5.5小时。

两周冲刺的典型日历

为了进行比较，让我们看看为期两周的Sprint。通常，我们的时间框对于两周的Sprint来说会稍微长一些，但令人惊讶的是，总体时间并不比我们的一周场景长。

一个进行为期两周的Sprint节奏的典型Scrum团队可能会在Sprint计划上花费两个小时。他们将每天进行15分钟的Daily Scrum。假设团队在Sprint的第一天没有进行每日Scrum，那么每日Scrum总共需要2.25小时。团队可能在Sprint评审上花费两个小时，在Sprint回顾上花费一个小时。总而言之，Scrum团队使用为期两周的Sprint，每两周将有9.25小时的时间用于Scrum事件以及细化会议。

如果您将总时间除以2，看看它与一周的Sprint相比如何，您会发现，平均而言，一个进行两周Sprint的团队每周将花费4.6小时用于Scrum事件加上改进。与运行一周Sprint的团队相比，在两周Sprint中进行每日Scrum的团队增加了一次，这是轻微的增加。

结论

Scrum中的时间框是为了节省时间，防止团队陷入无休止的讨论循环。因为Scrum是在复杂的环境中使用的，其中未知的比已知的要多，Scrum团队经常需要根据他们的经验来学习什么是有效的。这意味着他们的时间可以更好地投入到工作中，而不是事无巨细地计划和审查工作。时间盒强化了这一现实。