【本文翻译自Mike Cohn的博客What Happens & When During a Sprint】
当你知道何时以及为什么要举办每一个会议时，Scrum转型就更容易成功
译者注
原文将迭代计划、迭代审查、每日站会和迭代回顾等活动都称作“仪式（ceremony）”，译者觉得这种说法有点晦涩难懂，所以本文都译作了“会议（meeting）”。
成功的Scrum执行需要一些重要的会议，这包括迭代计划、迭代审查、每日站会和迭代回顾等。
人们关于谁应该参加这些会议、什么时候举行这些会议、每个会议需要多长时间、会议的目的等等，常常有很多困惑。
为了减少混淆，我们创建了如下的图表，回答了1-4周的迭代中遇到的上述问题。
迭代会议的日程规划
迭代计划会（The Sprint Planning Ceremony）
迭代计划标志着迭代的正式开始。一旦这个会议开始，迭代也就开始了。
SM、PO和开发团队都将参与。当PO和团队都认为合适的时候，也可以邀请其他人偶尔参加。例如，如果下一个迭代将要开发的功能最好由某个主题专家subject matter expert(他不是产品所有者)来解释的话，那么请该人员参加会很有用。然而，通常这种类型的讨论最好在实际的计划会议之外进行。
迭代计划会议的长度与迭代的长度成正比。四周的迭代，计划会议最好不超过8个小时，一周的迭代最好不超过2小时。
这些是最大的时间盒，我建议团队可以通过不断的迭代，将时间控制在最大时间盒的一半。
作为对迭代计划会议的输入，SM将带来有关团队平均速度（velocity）和最新速度的数据，PO将带来产品待办列表，或者至少是产品待办列表中优先级最高的条目。在许多团队中，PO还将提供一个迭代目标草案，该目标草案可以在计划过程中进行协作修订。
迭代计划的输出包括一个对即将到来的工作更加了解并为之做好了充分准备的团队。额外的产出包括一个迭代待办列表（sprint backlog）和商定的迭代目标。
每日站会（Daily Scrum）
每日例会（daily scrum），也称为每日站立（daily standup），是一个简短的、团队成员同步工作的每日会议。每日站会使团队成员能够确保正确的人在正确的时间处理正确的事情。
每天，每个参与者都要回答三个问题：
为了实现迭代目标，我昨天做了什么以？
为了实现迭代目标，我今天要做什么？
在实现目标时，有没有遇到一些障碍/阻碍？
问题可以用多种方式表达，例如，很多团队发现相比于描述“自己做了什么”，他们认为描述“完成了什么”更有利于目标的实现。
参与者包括SM、开发团队，在我看来，还有PO。
Scrum社区内部存在一些有关PO是否应参与的辩论，将PO从每日站会中排除出去，会使PO和团队造成隔阂。“我们和他们”的感觉已经存在于太多的组织中，我不知道为什么一个Scrum团队或它的PO会想要做任何事情来进一步强化这种消极态度。
每日站会的时间限制为15分钟，其目的是为了进行简短的更新和同步。与迭代计划不同，我不建议您尝试在推荐时间的一半内完成每日站会。对于大多数团队而言，仅5-7分钟的时间根本不足以提出任何实际问题或理解正在完成的工作。当团队将每日站会的时间缩短得太多时，会议就会变成一系列机械的更新，比如“昨天我做了这样那样的事，今天我要做这个和那个，没有什么问题阻碍我。”
每日站会没有正式的输入，唯一的输出是增加了开发团队的工作协调性。
迭代评审会（Sprint Review Ceremony）
迭代审核在迭代的最后一天进行。PO、SM、开发团队和任何相关的利益相关者（stakeholder）都应参加。利益相关者可能会根据迭代交付内容的不同而有所不同。
四周的迭代，审核会的时间最多为四个小时。时间会随着迭代时间的长短按比例放大缩小，对于一周的迭代，则缩短到一小时。
作为对迭代评审的输入，团队应演示本迭代所有符合完成定义（definition of done）的待办列表项，这意味着团队不会演示仍在进行中的工作。但是，有时可能需要对这一规则做些例外处理。
完成功能的演示是典型的迭代评审的中心活动，但大多数团队也会花时间来讨论进展和问题。您可以阅读我推荐的迭代评审议程。
完成功能的演示是典型的sprint评审的核心活动。但大多数团队也会花时间来讨论进展和问题。你可以阅读我推荐的sprint回顾议程。
评审的目的是征求一些在迭代期间构建结果的反馈。PO会考虑所有反馈，并可以适当地更改产品待办列表。因此，迭代评审的输出是一份改进的产品待办列表。
迭代回顾会（Sprint Retrospective Ceremony）
迭代回顾会是团队成员考虑如何改善工作方式的时间，这意味着他们可能会改变Scrum的一些方式，例如迭代的长度。但是回顾会还可以涵盖合作的一些方面，比如是否禁止早上的会议，哪些话题适合在Slack上讨论，哪些需要面对面的交流。
整个团队——也就是开发团队、SM和PO——都应该参加迭代回顾，否则就会在团队内部产生分裂。一个好的敏捷团队应该避免任何导致“我们/他们”思维模式的行为。
除了改进的意愿之外，迭代回顾没有正式的输入。输出是团队对其工作方式的改进列表。
四周的迭代，迭代回顾会的时间限制为3小时。回顾可能偶尔需要那么长的时间，但大多数团队大多数时候会在一小时内完成回顾。
产品待办列表梳理（Product Backlog Refinement）
产品待办列表梳理是指确保产品待办列表顶部的项目已准备好排入下一个迭代。这可以包括向现有条目（item）添加细节、估算、删除条目（item）、调整优先级、拆分产品待办列表项（product backlog items）以便更适合排入迭代、以及创建新条目（item）。
虽然产品待办列表梳理本身是必要的，但并不是强制要求团队将其作为一个正式的会议/仪式，或者在每个迭代中都要进行。然而，大多数团队会定期召开产品待办列表梳理会，通常每迭代一次或每周一次。
通常的指导原则是，无论在会议中，还是在可能由这些会议引发的讨论中，花费在改进产品待办列表的时间不应超过团队总可用时间的10％。
大多数团队将让整个开发团队、PO和SM一起参与。除非团队要在梳理会上对产品待办列表项估算，否则我发现开发团队的一半到三分之二就足够了，并且可以减轻团队的总体会议时间负担。
此流程的唯一输入是位于产品待办列表顶部的条目（items）。输出是产品待办列表项（product backlog items），这些待办事项通常被分割成更小的、更适迭代的条目，以及对某些产品待办列表项（product backlog items）的更深入理解。
待办事项估算（Backlog Estimating）
如上所述，许多团队将在产品待办列表项梳理会期间进行估算。这是一种理想的方法，如果整个开发团队都参与到梳理会中，那么这种方法是可行的。
如果只有部分开发团队成员参与了梳理会，那么团队成员将在每个迭代中开一次会，以估算任何PO可能需要评估的新工作。
对于大多数团队来说，这些估算会议应该很短。大多数团队不应该在每个迭代中生成或接收大量的新产品待办列表项。要估算的工作应该很重要，新的产品待办列表项或者已拆分的待办列表项，应更适合排入即将到来的迭代。
我喜欢在迭代结束前几天，每日站会之后立即进行产品待办列表的估算。没有必要等到所有待办列表项都被识别出来以后再估算，PO只要先识别出来重要的待办列表项即可开始估算，但是PO要及时根据估算的结果来调整优先级。
我喜欢在迭代结束前几天，每日站会之后立即进行产品待办列表的估算。这已经太晚了，大多数新项目都已经确定，但是及时地，产品所有者可以根据评估所传达的新信息调整优先级。
我不建议在迭代计划会期间进行估算，对于PO而言，此时根据估算来调整优先级为时已晚，PO调整优先级的动作会极大的浪费整个团队的时间。因此，请勿在迭代计划会期间对产品待办列表项进行估算。
优先级排序（Prioritization）
在开始新的迭代之前，PO应确保已将产品待办列表的顶部做了优先级排序。根据《Oxford American Dictionary》，优先级（prioritize）意味着“把任务、问题等按重要性排序，这样你就可以先处理最重要的事情。”
这意味着仅靠说“它们都是必需的”是不够的。或者，正如一位PO告诉我的那样：“它们被称为需求（requirements）是有原因的——它们是必需的（required）。”
在大多数情况下，不会举行正式的优先排序会议。相反，这是PO在与利益相关者对话以了解他们的需求和愿望之后独自做的事情。
优先级排序在迭代中应尽可能晚的进行，同时确保在下一个迭代开始之前完成。这通常意味着在迭代的最后一两天完成这件事。
通常，优先级排序并不会消耗很多时间。这是因为PO通常会根据进度和当前的迭代的经验来调整优先级，而不是对整个产品待办列表进行彻底的重新排序。
您何时举行这些会议？（When Do You Conduct These Ceremonies?）
您的团队何时举行这些仪式？您会推荐其他团队成员参加会议吗？您的参与者与我描述的相同吗？请在下面的评论中分享您的想法。
网友评论