本文是个人总结摘记，部分文字摘自其他大神博文等，如有雷同，未列参考文献，请见谅；

定义

  • IPM, Iteration Planning Meeting, 迭代计划会议，又称Sprint计划会议：是一个开发迭代周期开始的团队活动；简单的说，它主要负责定义和产出：哪些人（WHO）/ 什么时候、多长周期内（WHEN）/ 哪些任务（WHAT），产出INTERATION GOAL / INTERATION PLAN / RELESE PLAN;
  • 好处：能对迭代有一个清楚的总结，更好了解整体项目进度和迭代进度；明确迭代的整个团队目标以及个人目标，团队对于需求的理解达到了统一；确定所有任务的点数，风险在评估中更明显的暴露出来；
  • 下一个迭代的 Story; 对下一个迭代的期望; 团队的人员可用性; 风险的评估总结。

要点

  • 团队参与：
  • 参与人员：Product Owner 产品负责人 / scrum master 敏捷教练 / Product Designer / Iteration Master / Team Members (开发、测试)，尽量全员参与，会议上自己做出承诺，更有仪式感;
  • 步骤1 需求分解（预先准备）；会议前
  • PO / PD 确定需求、优先级，PO维护项目需求列表PB，根据上一迭代和PO反馈，新增、移除需求、或调整优先级;
  • 开发团队 Leader 应该预先了解团队接下来迭代的人力容量；
  • 会议前准备：1 备选的迭代 Backlog 2 迭代的目标；
  • 步骤2 明确迭代的目标；会议中
  • 总结迭代，明确这个迭代的产品优先级，需求分解的颗粒度更小，越容易做估算，排期计划才更准确;；
  • 明确和宣布迭代开始时间和结束时间、评审会议时间、回顾会议时间；
  • TMs 根据个人时间安排，计算可用资源；
  • 步骤3 团队估算/任务分配；会议中
  • SM 从排序的PB中选出一条, PO/PD进行讲解，TMs进行挑战，达成共识，添加验收条件；TMs共同估算工作量，pull or push PB； * 开发团队 Leader 带领团队成员，开始分配认领 UserStory，鼓励团队成员主动的 Pull（认领） ，而不是被动的接收 Leader 的 Push（被动接收）；
  • 开发团队 Leader 统一审视每个成员的实际工作量，避免对有些成员的工作量不均衡，并进行相应的调整。
  • 进行简单快速的头脑风暴，团队成员发表自己对于接下来迭代的风险，全员对这个迭代的目标进行信心投票，5 分信心最高，1 分信心最低，如果平均分低于 3 分，应该让投比较低的成员再讲讲他们的考虑，看看要不要再调整需求的优先级。
  • 会议结束，开始为这个迭代的目标而冲刺。

禁忌

  • 迭代会议预先准备是非常关键的。团队成员那么多，如果预先不进行备选 UserStory 的识别和排序，拿一堆颗粒度很大的需求直接去迭代会议，大概率要失败，会议也会及其冗长，那么多团队成员，时间是珍贵的；
  • 不要让计划会议变成PO或者SM，业务主管的个人发言；开发团队不需要在计划会议上考虑所有的细节，PO要进行引导，避免陷入太细节的讨论，也要避免陷入讨论跑题；

​​https://www.tapd.cn/forum/view/28751​​​

https://www.jianshu.com/p/36a69b44fc9e