实现成功的Scrum需要一些重要的仪式。这包括Sprint计划、Sprint回顾、每日Scrum等等。
通常会有很多关于谁参加、什么时候举行这些仪式、每个仪式需要多长时间、仪式的目的等等的困惑。
为了减少混乱，我们创建了信息图表，在1周、2周、3周和4周的冲刺中回答每个问题。
冲刺计划仪式
Sprint计划标志着冲刺的正式开始。 一旦这个仪式开始，冲刺也就开始了。
Scrum Master、产品所有者和开发团队都参与其中。其他人可能会在产品所有者和团队都认为合适的情况下参加。例如，如果即将到来的冲刺将包括由主题专家（不是产品所有者）最好地解释的开发功能，那么让该人参加会很有用。但是通常，这种讨论最好在实际计划会议之外进行。
冲刺计划仪式的长度与冲刺的长度成正比。应计划为期四周的冲刺，时间不超过8小时。应该在不超过两个小时的时间内计划为期一周的冲刺。
这些是时间框（最大值）。我建议团队在大约一半的允许时间内完成冲刺计划。
作为冲刺计划仪式的输入，Scrum Master将提供团队平均速度和最近速度的数据。产品所有者将在产品待办事项中，提供产品待办事项或至少最高优先级的项目。在许多团队中，产品所有者还将提供草案冲刺目标，可以通过规划流程进行协作修订。
sprint计划的输出包括一个更聪明的团队，并为即将到来的工作做好更充分的准备。其他输出包括sprint backlog 和一个商定的冲刺目标。
每日Scrum
每日scrum，也称为每日站立，是一个简短的每日仪式，在此期间团队成员同步工作。每日scrums使团队成员能够确保在适当的时间由合适的人员处理正确的事情。
每个参与者每天都会讨论三个主题：
我昨天做了什么来帮助实现冲刺目标？
今天我将如何实现冲刺目标？
什么，如果有什么阻碍或阻碍冲刺目标的进展？
问题可以通过多种方式表达。例如，许多团队发现参与者描述完成的内容， 而不是他们所做的事情，这样比较好。
参与者包括Scrum Master，开发团队，以及产品所有者。
Scrum 圈内部对于产品所有者是否应该参与有一些争论。从日常Scrum中删除产品所有者会在整个团队中产生分裂。「我们」和「他们」这种对立的感情已经存在于太多的组织中。我不知道为什么Scrum团队或其产品所有者会想要增强这种消极态度。
每日scrum限制为15分钟。目的是使其成为简短的更新和同步工作。与sprint计划不同，我不建议尝试在建议的时间段的一半内完成每日Scrum。对于大多数团队来说，5-7分钟根本不足以提出任何实际问题或了解正在完成的工作。当团队过多地缩短每日的scrums时，仪式将变成一系列死记硬背，例如“昨天我做了这样的事情。” 今天我会做到这一点。没有什么事在我的路上。“
每日scrum没有正式的输入，唯一的输出是开发团队提高工作的协调性。
Sprint评审仪式
冲刺回顾发生在冲刺的最后一天。产品所有者，Scrum Master，开发团队和其他利益相关者都应该参加。根据交付的内容，不通的冲刺之间，利益相关方参与者可能会各不相同。
对于为期四周的冲刺，冲刺审查的时间最多为四小时。对于较短的冲刺，它的比例较短，对于为期一周的冲刺，则为1小时。
作为Sprint评审的输入，团队应显示符合团队完成定义的所有产品待办事项。这意味着团队不会显示仍在进行中的工作。但是，有时可能值得对此规则进行例外处理。
演示完成的功能是典型冲刺审查的核心活动。但大多数团队也会花时间讨论进展和问题。
审查的目的是征求对sprint期间构建的内容的反馈意见。产品所有者会考虑所有反馈，并可以根据需要更改产品待办事项。因此，冲刺审查的输出是修订后的产品积压。
Sprint回顾仪式
Sprint 回顾仪式是团队成员考虑如何改善他们的工作方式的时候。这意味着他们可能会改变他们如何做scrum，例如他们的冲刺的长度。但回顾仪式也可以涵盖合作的一般方面，例如是否禁止早间会议或哪些主题适合在日事清讨论，以及哪些需要面对面交谈。
Sprint回顾应该由整个团队出席——即开发团队，Scrum Master和产品所有者。否则就是在团队中制造分裂。一个好的敏捷团队应该避免任何导致「我们」-「他们」对立心态的行为。
除了愿意改进之外，对Sprint回顾仪式没有正式的输入。输出是团队将对其工作方式所做的更改列表。
Sprint回顾仪式正式时间限制为3小时。回顾可能偶尔需要很长时间，但大多数团队将在一小时内进行大多数回顾。
产品Backlog改进
产品待办事项细化是指确保产品待办事项顶部的项目为下一个sprint做好准备。这可以包括向现有项目添加细节、删除项目、调整优先级、拆分产品积压项目以便更好地适应冲刺，以及创建新项目。
虽然产品Backlog改进本身是必要的，但团队并不是强制要求作为正式仪式进行改进，或者每次冲刺都要完成。但是，大多数团队将定期进行产品Backlog改进会议，通常每次冲刺一次或每周一次。
通常的指导是，在会议和可能由这些会议产生的讨论中，不超过团队总可用时间的10％用于产品Backlog改进。
大多数团队都会让整个开发团队与产品负责人和Scrum Master一起参与。除非团队在其改进会议期间估计产品积压项目，否则我发现可能有一半到三分之二的开发是足够的，并且减少了整个团队的会议时间负担。
此仪式的唯一输入是产品Backlog顶部的项目。输出是产品Backlog项目，通常被拆分为更小，更适合冲刺，以及更好地理解某些产品积压项目。
Backlog 估算
如上所述，许多团队将在产品积压改进会议期间进行估算。这是理想的方法，如果整个开发团队参与Backlog改进，这是可能的。
如果只有开发的一部分参与Backlog改进，团队成员将在每个sprint会面一次，以估计产品所有者可能需要估算的任何新工作。
对于大多数球队来说，这些估计仪式应该非常短。大多数团队不应该在每个sprint中生成或接收大量新产品Backlog项目。要估算的工作应该是重要的，新产品Backlog项目或已经拆分的现有项目，以便更好地适应即将到来的冲刺。
我喜欢在每天的scrum之后立即进行产品Backlog评估，这是在sprint结束前的几天。这已经足够晚了，大部分新项目将被确定，但及时让产品所有者根据估算所传达的新信息调整优先级。
我不建议在sprint计划期间进行估算。对于产品所有者来说，根据估算调整优先级为时已晚。这也会导致团队成员在估算时花费的时间超过预期。因此，不要在sprint计划期间估计产品积压项目。
优先级
在新的sprint开始之前，产品所有者确保优先考虑产品Backlog的顶部。根据牛津美国词典，优先排序意味着“按重要性排列任务，问题等，以便您可以首先处理最重要的事情。”
这意味着仅仅要说“它们都是必需的”，优先顺序是不够的。或者，正如一位产品所有者告诉我的那样，“他们被称为必需的理由是 - 他们是必需的。”
在大多数情况下，不会举行官方优先排序仪式。相反，这是产品所有者在与利益相关者进行对话以了解他们的需求和愿望后单独做的事情。
优先级应该在sprint中尽可能晚地发生，同时确保在下一个sprint之前完成。这通常意味着在冲刺的最后一天或两天进行。
通常，优先排序不是耗时的。这是因为产品所有者通常根据进度和从当前sprint中学习来优化优先级，而不是对整个产品积压进行彻底的重新优先级排序。
你什么时候举行这些仪式？
你的团队什么时候开展这些仪式？是否还有其他团队推荐的其他仪式？你的参与者和我描述的一样吗？
vv
