About scrum meetings

在Sprint中，ScrumMaster要确保没有任何影响Sprint目标的变更发生。团队构成和质量目标在Sprint中均保持不变。Sprint一个紧跟一个进行，之间没有任何时间间隔。发布计划确定发布目标、具有最高优先级的产品Backlog条目、重大风险和发布所包含的全部特性和功能。

在Scrum发布计划会议上确立一个整体目标和预期结果。发布计划会议通常不超过组织构建传统发布计划的15-20%时间。发布计划会议需要为该发布做产品Backlog条目的估算和优先级排列。

Sprint计划会议的产物是Sprint Backlog。计划会议一般安排整个Sprint周期的5%时间。Sprint计划会议包含两部分内容：“做什么”和“怎么做”。一些Scrum团队将这两部分结合起来。第一部分，Scrum团队处理“做什么”的问题。
产品负责人给团队介绍最高优先级的产品Backlog条目，并一起决定接下来的Sprint中开发什么功能。Sprint计划会议需要输入包括产品Backlog、最新的产品增量、团队的能力和以往的表现。团队自己决定选择多少产品Backlog的条目，因为只有团队可以评估在接下来的Sprint内可以完成什么工作。选定产品Backlog条目后，Sprint目标也就明确了。确定Sprint目标的原因是在功能方面为团队留出一定的回旋余地。例如，上一个Sprint的目标可能是：“通过一种安全、可重获的交易中间件实现客户账户修改功能的自动化”。所以当团队工作时，就会紧记这个目标。为了达到这个目标，团队就需要实现该功能和技术。如果团队感觉实现过程比预期的难度大，那么就可以和产品负责人协商，只实现部分功能。
在Sprint计划会议的第二部分，团队需要处理“怎么做”的问题。在Sprint计划会议的第二个4小时时间箱中，团队需要弄清楚如何将“做什么”会议阶段选定的产品Backlog条目转化成完成的增量。通常团队会先以设计展开工作，设计过程中，团队确定任务，这些任务就是将产品Backlog转化成可用软件的具体工作。任务需要被分解，以便在一天之内完成。这个任务列表就是SprintBacklog。团队通过自组织，并且是自己认领的方式分担任务，任务认领可以在Sprint计划会议上进行，或也可以Sprint中及时（Just-in-time）确定。产品负责人会参加Sprint计划会议的第二部分，为团队讲解产品Backlog条目，并协助团队权衡取舍。如果团队认为工作量过大或太小，就可以和产品负责人重新协商、确定产品Backlog。

新组建的团队常常在这次会议中第一次意识到：整个团队要么一起成功，要么一起失败，没有个体这个概念。团队同时认识到必须依靠自己。正因为意识到这一点，整个团队才逐渐自组织并形成自己的特色，真正成为一个团队。

Sprint结束时要举行Sprint评审会议，该会议的时长不要超过整个Sprint的5%。 评审会议至少要包含以下因素：产品负责人确定完成了哪些工作和剩余哪些工作。团队讨论在Sprint中哪些工作进展顺利、遇到了什么问题、问题是如何解决的。然后，团队演示完成的工作并答疑。产品负责人和与会人员讨论产品Backlog，并根据不同的速率计划出可能的完成日期。接着，整个团体就哪些工作已经完成，同时这对下一步工作有何意义进行探讨。Sprint评审会议为接下来的Sprint计划会议提供了宝贵的参考信息。

在Sprint评审会议结束之后和下个Sprint计划会议之前，Scrum团队需要举行Sprint回顾会议。对于长度为一个月的Sprint，回顾会议的长度一般为3小时。回顾会议旨在对前一个Sprint周期中的人、关系、过程和工具进行检验。检验应当确定并重点发展那些进展顺利的，和那些如果采用不同方法可以取得更好效果的条目。这些包括：Scrum团队、会议安排、工具、“完成”定义、沟通方法和将产品Backlog条目转化成“完成”工作的过程。在Sprint回顾会议的最后，Scrum团队应该确定将要在下个Sprint中实现的有效改进方法。这些变化更适应于经验检验。