迭代计划会
目的
团队明确一个短周期内的承诺的交付范围，符合团队的实际容量 所有工作有明确的责任人
一般在迭代第1天商务召开，PO、DM、Team全员参与，由DM主导
活动
- 对需求梳理会上未解答的遗留问题进行解答，未估点的补估点
- PO或DM给团队介绍故事优先级（应提前在工具里）
- 团队明确自己本迭代的可用容量大小
- 团队按优先级从高到低，一起选择合适数量的工作项放进可承诺的迭代计划中
- 团队可额外再挑选少量的（2~3个）工作项作为迭代挑战目标
- 团队成员从确定的迭代计划中认领自己负责的工作项
输出
- 明确的迭代计划（故事列表、优先级）
- 每个故事的负责人，及合作参与者
迭代计划会—关键要点
会前
- 故事拆分到了合理大小，AC明确
- 提前进行了需求梳理会和估点，提前发现和解决需求问题，不应过多在计划会讨论方案和问题
- 负责需求的技术方案已经评审通过
- 需求的风险和外部依赖很清楚，并且风险可控
会中
- PO或DM要给出迭代中故事的明确优先级顺序
- 以故事能完成开发和测试作为可承诺的标准，否则不纳入计划，或仅作为挑战目标
- 要清楚团队容量，前期基于计算，几次迭代之后参考历史速率，同时考虑以下因素降低可用容量：
- 期间的年假安排
- 个别人休假计划
- 个别人兼职工作
- 生产问题支持的投入预留
会后
- 团队重视承诺，计划的一定努力达成！
- 每个故事的负责人，当开卡开始开发时，给出故事的计划转测日期，记录在卡片上；
- DM注意合理安排故事开卡，不要让所有故事都堆在迭代最后几天转测
- 新的迭代计划更新到物理看板；
- 测试在每个卡开始开发前或同步完成测试场景分析，并与参与的开发人员一起评审完善。
常见问题
1、PO在什么阶段产出什么？ PVR会前 新专题的画布（用户、待解决问题、价值、需求概述、风险等） 可能的月度/季度规划更新 设计评审会前 关键页面原型或线框图 故事地图（迭代滚动规划更新） 需求梳理会前 必要的完整原型 故事拆分与书写（Card与AC） 迭代计划会前 梳理会上提出的原型或故事问题的确认、更新
2、迭代遗留的故事影响下迭代计划，和对业务的承诺？
避免过度承诺
- 首先，迭代完成率并非总是100%就是最好的，可能说明团队缺乏挑战80%左右比较合理；
- 团队一定要避免过度承诺，迭代计划必须要依据团队实际容量，若持续迭代完成率太低会让迭代计划不再可信！团队成员也不在意迭代承诺！
- 若迭代容量总是超量，通过持续加班来完成，必定交付质量不好！更伤害团队积极性和稳定性。
- 从故事地图规划开始，要积极管理依赖和风险（有可能延期的故事），寻求支持及早解决；避免随意承诺有风险的故事，尽早给业务提示风险！已知迭代无法完成的故事要尽及时与业务沟通原因，而不是等到最后一刻。
（迭代结束时）延期时的处理
- 剩余工作量大或开始的故事，将整个故事移动到下个迭代计划中继续工作，并与业务沟通计划调整；
- 下个迭代的计划要为推迟的故事预留时间，不能满符合计划新的需求，避免恶性循环；
- 回顾，团队反思导致延期的原因，认识团队实际容量，制定切实的改进的措施；
适当缩小后续的计划量，管理业务期望，不要过早承诺，减少倒排，提升下作，更积极管理依赖和风险，提升自动化构建、测试和部署等；
阅读更多[敏捷知识]、[敏捷转型经验]、实践等…欢迎关注掘金账号@鲸舟研发管理
如果对我们的产品感兴趣，可以逛逛我们的官方网站鲸舟研发管理平台 试用了解
