Scrum事件概述
Scrum事件是Scrum框架的关键元素。它们为践行Scrum的三大支柱——检查、适应和透明提供了常规的机会。此外,这些事件帮助团队与Sprint目标和产品目标保持一致,提高开发人员的生产力,消除障碍,并减少安排过多额外会议的需求。
共有五个Scrum事件(Sprint、Sprint计划会、Daily Scrum、Sprint评审、Sprint回顾),每个事件都有其特定的目的、时间限制和参与者。
目的
虽然详细了解每个事件对于有效运用Scrum非常重要,但从最高层次来看,每个事件的目的实际上相当简单:
Sprint — Scrum中的所有工作都是在一个称为Sprints的一系列短小项目中完成的。这使得快速反馈环成为可能。
Sprint计划会(Sprint Planning) — Sprint从一个规划会议开始,在这个会议上,开发人员规划他们在Sprint中打算完成的工作。这一计划为团队成员创造共识和一致性。
Daily Scrum — 开发人员每天碰面,检视他们向Sprint目标进展的情况,讨论遇到的任何挑战,并根据需要调整接下来一天的计划。
Sprint评审(Sprint Review) — 在Sprint结束时,Scrum团队与利益相关者会面,展示他们的成果并获取反馈。
Sprint回顾(Sprint Retrospective) — 最后,Scrum团队聚在一起讨论Sprint的过程,看是否有可以在下一个Sprint中换个做法和改进的方面。
*这些描述是介绍性的,我们强烈建议对每个事件有更深入的理解。
时间限制
为了帮助创建纪律性和专注力,每个Scrum事件都有预定义的时间限制,或称为时间盒:
- Sprint的时间盒不超过一个月,尽管它们通常持续两周。
- 对于一个月的Sprint,Sprint计划会、Sprint评审和Sprint回顾的时间盒限制分别为8小时、4小时和3小时。当Sprint短于一个月时,团队通常会将这些事件的最大持续时间设定为更短。
- 无论 Sprint 的长度如何,Daily Scrum的时间盒都为15分钟。
这些时间盒使得会议能够高效进行,鼓励与事件目的相关的讨论,而不相关的对话则不被鼓励。如果团队能够在分配的最大时间内提前达成时间盒事件(Sprint计划, Daily Scrum, Sprint评审 和 Sprint回顾)的目的,他们应该直接结束会议。
当团队无法在规定的时间盒内达成事件的目的时,团队应当调查可以在哪些方面寻找改进的机会,以改善他们如何开展这些事件。
将焦点集中在时间盒内的事件是一种纪律,它允许团队成员减少开会的时间,从而腾出更多时间来做其他工作。
参与者
每个活动都需要 Scrum 团队的参与者。并非所有会议都需要所有 Scrum 团队成员。特别是对于 Sprint 评审,有必要邀请 Scrum 团队以外的人员提供反馈和建议。每个活动都有合适的参与者可确保会议专注于其目的。
Scrum事件快速参考
以下是有时间盒限制的 Scrum 事件的简要概述。Sprint 是所有这些事件的容器,最长持续时间不得超过一个月。
事件 |
检视 |
适应 |
参与者 |
时间盒 |
Sprint计划 |
产品待办列表、产品目标、完成 的定义 |
Sprint 待办事项、Sprint 目标 |
Scrum 团队 |
为期 1 个月的 Sprint 耗时 8 小时 |
Daily Scrum |
Sprint目标进展 |
Sprint 待办事项 |
开发人员 |
15 分钟 |
Sprint评审 |
增量、冲刺、产品待办事项、产品目标进展 |
产品待办事项 |
Scrum 团队、利益相关者 |
为期 1 个月的 Sprint 耗时 4 小时 |
Sprint回顾 |
Sprint,完成的定义 |
可操作的改进,完成的定义 |
Scrum 团队 |
为期 1 个月的 Sprint 需要 3 个小时 |
让你的Scrum事件更高效
每个Scrum事件的目的、时间盒和参与者都是明确定义的。然而,我们有时会看到Scrum团队陷入一些反模式,这些反模式削弱了这些事件的价值。
常见的反模式包括:
- 事件经常超出其时间盒:当参与者失去对事件目的的关注时,这种情况可能发生。团队往往会偏离主题进行额外的对话,而不是专注于会议的目的,并安排另一次会议来解决在事件中发现的问题。
- 并非所有团队成员都被“听到”:如果团队成员感到不适于表达自己的想法,团队将无法充分利用他们的技能和经验,这会削弱事件的价值。
- Scrum Master主导讨论,且团队成员向Scrum Master发表意见:每个Scrum事件都有其独特的目的,它们都是为了参与者共同协作,以检查和调整他们朝着产品或Sprint目标的进展。Scrum Master的角色是帮助团队实现每个事件的目的。
- Scrum事件变成了状态报告会议:这些事件都不是状态报告会议,而是旨在帮助团队朝产品或Spirnt目标前进。
- 团队决定取消某些事件,因为他们觉得Scrum会议过多:每个Scrum事件都有其目的,每个团队成员都应对确保每个事件的有效性负责。持续改进有助于团队随着时间推移变得更为高效和有目的性。如果团队觉得Sprint计划、Sprint评审和Sprint 回顾过于频繁且价值有限,那么也许可以考虑延长Sprint的长度。但应谨慎行事,因为Scrum的一个基本原则是提供频繁的检查和调整机会。
- 团队成员等到下一个事件才采取行动,而不是立即行动:虽然Scrum事件为检查和调整提供了预定的机会,但如果团队发现需求需要调整,应该尽快执行变更。
- Scrum Master总是主持事件:任何团队成员都可以主持Scrum事件,没有谁正式负责成为会议主持人。尽管如此,选择成为Scrum Master的人通常会选择发展其引导技能,并可能被要求带领某些事件。
- Scrum团队成员拒绝在Sprint期间召开或参加非事件会议:Scrum团队往往需要协作解决工作中出现的问题和挑战。针对特定挑战的单独会议有助于团队集思广益并达成最佳解决方案。
- 开发人员仅参与Daily Scrum而在其他事件中扮演被动角色:开发人员的专业技能、知识和经验对于所有Scrum事件达到其目的都是必要的。开发人员的参与总是能增加价值。
强化Scrum事件的小贴士
打破上述反模式有助于创建强大而有效的Scrum事件。请考虑以下建议:
- 确保每个人都有发言权
- 确保每个人都保持一致;鼓励所有人提问
- 确保后续讨论得到处理
- 确保信息来源得到更新
- 确保会议忠实于其目的
- 确保会议对所有参与者都有价值
- 确保障碍被识别并处理
- 确保一切透明
- 确保每个团队成员都拥有他们所需要的东西
详细了解各Scrum事件
什么是 Sprint?
什么是 Sprint Planning?
什么是 Daily Scrum?
什么是 Sprint Review?
什么是 Sprint Retrospective?