敏捷的迭代实现始于计划会议，所以一个好的计划会议是每个迭代成功的基础；Scrum站立会议，可以有效反馈项目存在的问题，及时跟进；Scrum验收会议，是在迭代结束前给产品负责人演示并接受评价的会议，以根据反馈结果，提出新的产品Backlog；Scrum回顾会议，在每个迭代结束后召开的关于自我持续改进的会议。
这些会议究竟怎么开，对项目研发有什么具体的帮助呢？
一、计划会议
视频地址：https://www.zentao.net/scrum/planmeeting-part2-80184.html/?f=bokeyuan
计划会议的意义是让团队共同确认和理解本次Sprint要完成的工作。参与本次Sprint的所有人员都要参加。
计划会议的第一步，是产品负责人向团队成员详细讲解每一个User Story。讲解后并对User Story进行排序和估算，团队集体参与，可以借助敏捷扑克牌来进行集体估算。最终制定出这一期Sprint要完成的Story列表，即Sprint Backlog。与会人员应认真听产品负责人的讲解，并发表自己的意见，以确保自己对每一个Story理解都是正确的。
我们在分析用户故事时，要清楚用户的根本需求，从而制定最佳解决方案，问题的最优解往往要考虑其投入产出比。
视频中讲述的空肥皂盒的故事，其实就是说，不应该对某种方案简单否定、教条照搬别人的方案，而是要根据自己的实际情况采用灵活的解决方案。
计划会议中，Sprint Backlog的制定，是整个Scrum团队基于自身情况共同商议讨论的结果，而不是产品负责人自己独裁决定的。Sprint Backlog制定出来后，下一步就是要对Story进行任务分解和领取。
在确认了Sprint Backlog之后，计划会议的第二部分是团队对每一个Story进行任务分解并自由领取。 分解的标准是将完成该Story所要做的所有任务进行分解。当然，这些任务不仅仅是开发的，也可能包括非开发性事务。如文档撰写、销售联系、付款采购等等。分解任务后，大家自愿领取喜欢的任务，并完成工时的预估，最终每个任务都有明确的负责人。
要注意：任务的领取要遵守自由、自愿的原则，而不是由项目经理硬性指派并指定工时。
计划会议中，为什么任务可以自由领取，并且不怕团队成员多估工时呢？主要有以下几个原因：
1. 开发人员自己领取，并做估算，是对团队的一种承诺。
2. 任务的规模大家有共识，加上良性竞争，所以不怕故意高估工时。
3. 每天召开站立会议也会及时同步信息，保证信息公开透明。
4. 借助禅道项目管理软件的工时、动态、燃尽图等功能，及时了解大家的工作情况。
二、站立会议
在Scrum站立会议中，可能有不同部门或岗位的人一起参加，但是要注意，只有真正参与项目的人才有发言权。
会议中可准备一个话筒或道具，只有拿着该道具的人才能发言，每个人说一下昨天做了什么，今天做什么，以及遇到的问题，但会议中并不去解决问题，可以会后探讨。 其他非参与项目的与会人员可以旁听，但不可喧宾夺主，每个人的角色、职责不同。
视频中跟大家分享了猪与鸡的故事， 在Scrum中，猪包括Scrum Master 、产品所有者、开发团队等成员，而客户，市场商务人员都是Scrum中的鸡。猪才是团队的核心，拥有较大的话语权。
但实际项目中往往是猪类角色没有发言，而鸡类角色喋喋不休，最后每个决定却让猪去承担后果，这是Scrum要尽力避免的。
三、验收会议
视频地址：https://www.zentao.net/scrum/Sprintreviewmeeting-80187.html/?f=bokeyuan
每次迭代结束后，团队需要召开迭代验收会议，展示本次迭代取得的进展。在验收会议中，Scrum团队成员可以采用demo的方式来演示完成的功能或者改进。
在上期视频中，我们介绍了站立会议中“猪”与“鸡”的角色，像研发人员等“猪”类角色是团队的核心，可以在站立会议中发言，而像市场销售等“鸡”类角色，在站立会议中是不能发言的。不过，风水轮流转，在验收会议中，终于轮到他们登场了。
验收会议是一个非正式会议，并不是进度汇报会议，无需整理幻灯片，只要提前准备下要演示的内容即可。
验收会议的意义并非单纯的演示，最主要的目的是通过演示获取反馈，从而促进产品优化改进。根据最后的完成情况，所有参会人员协同讨论，并记录下发现的Bug及问题。
验收会议中，整个团队都需要参加，并会邀请所有与产品相关人员参加。会议的结果产出，也就是演示过程中，发现、商讨并记录的所有问题，会列入到Product Backlog中，以便产品负责人后期管理。
四、回顾会议
Scrum回顾会议是一个周期性的回顾，总结工作中的经验和教训。回顾会议发生在验收会议结束之后，下个迭代计划会议之前。时间一般为1-2小时。Scrum团队所有成员都要参加，Scrum Master要确保回顾会议的正常举行。
回顾会议旨在对前一个迭代周期中的人、关系、过程和工具进行检验。从而明确了团队接下来要开始做什么，停止做什么，以及继续做什么。
比如：下个迭代要修复上期迭代中已发现、记录的bug问题；
之前团队开站立会议时不同角色沟通发言的方式不对，我们要停止并进行改善；
我们之前采用的结对编程感觉效果不错，所以后面可以继续做。
Scrum团队中，除了产品的迭代改进，团队的技术实践同样需要逐步优化改进。很多Scrum团队对于回顾会议并没有足够的重视，甚至直接跳过了这一步。
如果不开回顾会议会有什么问题呢？
会导致对于项目结果及过程中的问题不清晰，长此以往，技术债务累积，最终导致项目失败。所以，回顾会议必不可少，Scrum Master应该鼓励团队在Scrum的流程框架内改进开发过程和实践，使得团队能在下个迭代中更高效。
而实际要开好回顾会议也并非易事。
召开回顾会议的最高指导原则是：“相信每个人当时都是尽了最大的努力。”这样可以给团队创造安全环境，避免开成“抱怨会”或“甩锅会”。
另外，Scrum项目中要避免“六拍”，下面给大家再讲一个猪与鸡的故事。继上次猪与鸡合作失败之后，他们又开启了第二轮创业。这回成功了吗？快去看视频吧~
Scrum回顾会议要求Scrum Master 要有足够的协调能力并活跃会议氛围，以提升团队成员的参与积极性，促使大家能够说出真实的想法，并发掘更有效的改进建议。在回顾会议的最后，Scrum团队应该确定在下个迭代中将要实现的有效改进方法，并在接下来的迭代中付诸行动。