Scrum框架包含五个事件。每一个事件都是一次检查与调整的机会——通过持续学习、调整方向和改进，让团队不断变得更好。
这些事件为Scrum团队提供了“恰到好处”的结构，帮助团队有效协作。但任何好东西一旦过量，也可能带来大量浪费。冗长、拖沓的Scrum事件，几乎从来都不是一件好事。
这就是为什么每个Scrum事件都有一个时间盒。这些时间盒是上限，并非建议时长。目标是让Scrum事件刚好能实现其目的，不多不少。
Sprint
Sprint的时间盒最长为一个月。
在这个范围内，Sprint应该长到足以让开发人员交付一个“完成”的增量，但不要更长。
对于软件团队来说，两周Sprint最为常见。有些团队更喜欢一周的Sprint，也有一些团队采用三周Sprint。而交付实体硬件的团队，可能需要完整的一个月。
更长的Sprint意味着反馈来得更晚，也意味着团队会在一个可能最终无法奏效的方案上投入更多。同时，Sprint越长，最终交付的内容偏离利益相关者需求的可能性也越高。
从这个角度来看，Sprint本身就是一种风险控制的时间盒：通常来说，越短越好。
Sprint的长度也决定了产品负责人可以多频繁地在Sprint评审会上与利益相关者交流，并根据真实反馈调整产品方向。
Scrum团队应该根据自己的具体情况决定什么样的Sprint长度最合适。
如果拿不准，就选择更短的Sprint周期。
Sprint Planning
对于一个月的Sprint，Sprint Planning的时间盒最长为8小时。
我曾经完整参加过一次持续8小时的Sprint Planning。
不瞒你说，非常糟糕。
问题在于，我们试图在这场会议中同时完成估算和精化。这实在太多了。
下一次Sprint开始之前，我们提前完成了产品待办列表的精化。从那以后，我们的Sprint Planning从来没有超过一个小时。
在这一个小时里，我们制定Sprint Goal，选择能够交付的产品待办列表项，并制定完成Sprint工作的计划。这些就够了。
没有人希望仅仅为了开会而开会。让Sprint Planning聚焦于它真正的目的，当目的达成时，就结束会议。
Daily Scrum
Daily Scrum的时间盒是15分钟。遗憾的是，这是最容易被开得过长的Scrum事件。
刚成为Scrum Master的时候，我经常让Daily Scrum持续一个小时。当时我告诉自己，我是在给团队提供更多协作的空间，是在帮助他们。
后来，团队中的几个人要求我把Daily Scrum控制在时间盒以内。我并没有这么做，于是有些人开始不参加。最后，所有人都不来了。
Daily Scrum不是团队建设会议，不是问题解决会议，甚至也不是状态汇报会议。
Daily Scrum的存在，是为了让开发人员规划接下来24小时的工作，并暴露阻碍。
所以，识别阻碍，讨论接下来24小时的工作计划。然后，回去工作。
需要解决的问题，在15分钟时间盒之外继续讨论。保持简短，但要有效。
Sprint Review
Sprint Review的最大时间盒是4小时。
我曾经参加过一次开满4小时时间盒的Sprint Review。既无聊，又让人不堪重负。后来，利益相关者告诉我们，这场会议需要更短一些。
从那以后，我们把Sprint Review控制在大约一个小时。我们重点讨论上一Sprint完成的关键成果，展示增量，并与利益相关者进行快速但有意义的协作。
Sprint Review的目的是透明、检视和调整。
它不应该是一场全面的产品演示，更不应该变成一场汇报。
Sprint Retrospective
Sprint Retrospective的最大时间盒是3小时。
在使用Scrum超过20年的时间里，我从来没有参加过一次真正需要完整3小时的Sprint Retrospective。
不过，这恰恰是Scrum Master最有价值的事件。
Sprint Retrospective的目的，是规划提高质量和有效性的方法。但这并不意味着它应该一直开下去。
它需要足够深入，能够产生有意义的对话，但不应该没完没了。
让Sprint Retrospective保持活力的三个方法：
1. 让Scrum Master之外的人来主持
这向团队传递了一个重要的信息：这是团队的事件，每个人都应该关心持续改进。
2. 在合适的时候，只聚焦一个问题
有时候，团队需要集中精力解决某个具体问题。可以使用“五个为什么”等方法，深入寻找问题背后的根本原因。
3. 有时候，经典方法依然很好用
例如：“哪些事情进展顺利？哪些方面做得不好？我们有哪些改进建议？”
这些方法之所以一直流行，自然有它的原因。
无论采用什么方式，都要始终记住：Sprint Retrospective的目标是持续改进。
简洁高效的会议能够确保会议重点突出、切中要点。更重要的是，这种时间限制内的会议还能激发创造力。
模式
Scrum提供了恰到好处的结构，帮助团队成员进行协作，但又不会因为过多的流程和结构而拖慢团队。
对于每一个Scrum事件，只使用实现其目的所需要的时间。
当Scrum事件更短、更聚焦时，团队能更好地进行检视和调整，还能有更高的参与度。
所以，让Scrum事件保持简短，始终目的明确。团队会感谢你的。
作者：Mary Iqbal
原文地址：https://www.scrum.org/resources/blog/keep-scrum-events-short
