目录
前言
整体介绍
输入
过程
输出物
前言
敏捷管理过程中迭代计划会是重要的一环，决定了你的团队在这个迭代中要完成什么具体的事项，它是对迭代目标进行细化后的产物，它可以用来进行迭代追踪，帮助你达成迭代目标，实现团队的价值。那么，一个正常的迭代计划表应该包含什么内容？一个很好的迭代计划表又应该包含什么内容呢？迭代计划表由哪些部分构成的？这些都是需要体系化的了解，我作为敏捷SM有一段时间了，正好进行一个总结来回答这些问题。
整体介绍
对于计划会来讲，明确本轮迭代要完成的任务，和团队成员就目标达成共识是我们的主要目的，当然还包括故事点估算，需求澄清等。
会议输入
输入的是经过PO和规划决策好了的，产品需要做的一些事情，比如产品需求，改进项，bug处理等等，会整体的给出需要完成的事情，但是没有具体到人，具体到交付的时间。那么计划会就是对这些事情进行进一步的细化，让工作具体到人，确定交付时间。
会议过程
迭代计划会议在每个迭代的起始阶段进行，迭代计划会议由SM支持，参与人包括产品负责人PO、团队成员（规划人员、市场代表、研发代表）。迭代计划会议划分为两个部分：
第一个部分：（PO、SM、团队)
1、PO向与会人员阐述下一个迭代的范围和大致目标，确保团队对下一个迭代的目标和范围达成一致理解；
2、PO向与会人员逐一讲解PB表中PO计划在该迭代实现的高优先级条目，确保团队对条目达成一致理解，同时，PO和团队共同评审每一个条目必须达到的验收准则。
第二个部分：（PO保持联系即可，不强求一定参会）
1、团队估算每一成员可以投入到下一个迭代相关的工作时间；
2、团队共同决定承诺在下一个迭代完成多少任务：团队从PB表的最顶端开始，估算其工作量，并将其分配为个人任务（推荐主动认领），并记录在下一个迭代SB表中，直到消耗尽所有可投入时间；这里估算工作量可以邀请每个开发都说明下工作点在哪里，注意事项，或者问比较有经验的开发人员，再或者是便利贴每个人分析后给出，这样不会收到其他人的影响，给出的也就更加的客观公正；
3、团队就下一个迭代的目标达成一致；
4、与会人员针对已识别的风险（资源、关键依赖等）进行讨论，明确初步的风险应对，并纳入风险管理。
会议输出物
输出清晰的迭代目标，细化后的迭代计划表，包括任务优先级，时间，负责人，验收准则，风险项等。
注意事项
真正要把评审会开好，除了会前的充分准备以外，会议过程的引导也至关重要。对于计划会来讲，明确本轮迭代要完成的任务，和团队成员就目标达成共识是我们的目的，所以开展正确的引导，避免大家在过程中太过发散、无法收敛，导致会议超时，影响参会者的体验。过程中鼓励团队成员自主Pull，而不是一味着的Push相信团队，相信团队对工作量的估算，给团队以尊重，工作量不要压得那么慢，超出人力容量的迭代，质量很难得到必要的保证。任何一个新的方法、框架在落地过程中，一定会有各种各样的问题，很难立马达成我们想要的结果，所以Scrum的会议本身也是在实战过程中迭代改进的，不是靠理论就能做好的，纸上得来终觉浅，绝知此事要躬行。希望团队能够基于实际问题出发，大家一起讨论、寻求解决方案，在实践中逐步迭代、达到预期的目的。关于Task的使用误区a）把什么都当Task。Task是为这个迭代服务的，是必须有产出。学习了什么这个不可以算作这个迭代的Task。b）把有些不当做Task。搭建环境，准备代码库或代码分支，验收，刷新自动化测试用例，这些都是要算Task的，不是只有写代码才算Task。总结
从上面可以得出，一个好的回顾会具备的要素有哪些，以及如何准备和开好回顾会了，最后一句话，秉持精益思想，小步快跑，不断迭代改进。
