Scrum 团队在迭代打算会议（Sprint Planning Meeting）中确定迭代指标，切磋并制订迭代待办列表，为后续开发做十全筹备。
- 会议第一阶段：产品负责人 PO 根据最新的产品需要列表（Product Backlog），阐明本次迭代须要实现的指标，并同 Scrum Master 和开发团队一起探讨实现目标须要实现的需要我的项目（Product Backlog Item，即 PBI）；
- 会议第二阶段：Scrum Master 和开发团队在 PO 的阐明和解释下，确定 PBI 的需要外延，将需要向下拆解成用户故事和子工作，同时实现故事估算、优先级排序和子工作归属等环节，制订所有人认可的迭代待办列表。
迭代打算会议的会议流程大抵如下：
- 明确迭代指标，全员达成共识
- 共享并探讨影响迭代的重要信息更新
- 确定最新的团队研发速率
- 联合假期、会议等，确定团队研发能力
- 打消影响往迭代进行的麻利阻碍
- 从新扫视 DoD，进行适当更新
- 确定待实现的 PBI
- 通过需要拆解、研发估算和工作认领，制订迭代待办列表
- 明确需要要点，制订故事的验收规范
- 记录布局中呈现的新问题，标记故事间的依赖关系
- 确认迭代指标和待办列表的共识，会议完结
迭代打算会议完结时，必须保障产品负责人 PO、Scrum Master 和开发团队都对「迭代指标」和「迭代待办列表」持有对立且清晰的了解和认知，即 团队中的所有人对迭代完结所需交付的价值增量有雷同了解。
Scrum Timeboxing 规定，打算会议的时长限度规范为 2 小时 / 周，即一个为期 2 周的迭代，其打算会议时长不超过 4 个小时。
想要在几个小时内高效地实现上述步骤，就必须进步规范建设、优先级排序、需要拆分和研发估算四个关键环节的效率。
1 规范建设
推动高效会议的第一步，就是保障 PBI 可能在不同职能间毫无阻碍地顺畅流转。
掐头去尾地说，迭代打算会议就是有从 Product Backlog 中挑选出 Sprint Backlog 的过程。一旦 PBI 须要破费大量的工夫能力被全员了解和承受，那就会迁延会议过程。
因而，建设准备就绪的定义即 DoR，由开发团队向 PO 提出接收 PBI 的最低标准，就能在打算会议中进步需要沟通和了解的效率。
同样的，Scrum 团队也能够建设 DoD 对需要转出做出标准，为用户故事制订验收规范，在保障信息通明的同时，对立不同职能成员对价值增量和需要外延的了解，打消潜在的共识阻碍，以独特的规范推动工作。
随着迭代循环的继续进行，DoR 和 DoD 也应该一直地做出优化和更新，通过新增或删减条款驱动更严密的合作。
2 优先级排序
麻利开发最外围的工作之一就是对需要价值进行优先级排序。无论 Product Backlog 还是 Sprint Backlog，都要建设清晰的价值排序，决出研发工作实现的先后顺序。
- PO 保护 Product Backlog 能够联合 公司文化、愿景和战略目标 等大方向上的已知决策，使用激进愿景工作表实现 PBI 的排序调整；
- Sprint Backlog 的保护和优先排序则应该联合 迭代指标、Product Backlog 的优先程序和迭代工作的关联关系 等因素判断实现。
需要优先级排序中，被广泛应用的三个模型别离是卡诺模型、机会评分和优先扑克。
- 卡诺模型 将待开发性能划分为必备型、兴奋型和期待型三类，通过「满意度」和「具备度」两项指标的标注，提供简洁但高效的优先级评估后果。
- 机会评分 建设了「客户满意度」与性能价值的间接关联：机会评分越高示意性能的客户满意度越高，则其优先级也越高；
- 优先扑克 邀请团队成员和要害利益相关者一起对性能重要性进行投票，通过后果的剖析排序，得出性能开发优先等级。
3 需要拆分
在打算会议的第二个阶段，开发团队和 Scrum Master 会在了解需要价值的根底上，对能实现迭代指标的 PBI 做出进一步的细分和拆解，并通过成员认领子工作的形式实现工作归属。
在之前的多篇文章中，咱们剖析过，体量更小的需要 有助于更好地布局和兼顾团队资源，防止研发过程中的重复探讨和精力节约，而 需要应该被纵向地、垂直地切分 成可能在一个迭代周期内实现的用户故事，以实现价值增量的疾速交付。研发团队能够依据 SPIDR 框架 或者 需要切分的九种办法，将需要拆分成合乎 INVEST 准则的、可独立交付价值的故事。
迭代打算会议上，Scrum Master 和开发团队还会围绕「如何实现迭代指标」，将用户故事再进一步拆解成合乎 0/1 判断要求的子工作。个别咱们倡议，子工作的工作量设置为 0.5~1 人 / 天最为适合。
把握需要拆分和用户故事拆解的规范，能减速团队实现会议第二阶段的指标，更高效地输入 Sprint Backlog。
当然，如果 PO 可能提供合乎开发规范的 PBI 也会在肯定水平上进步会议第一阶段的效率。改良需要形容形式，优化用户故事或者驳回「结构化语言工具」等形式都有助于传递更清晰的需要价值，缩小重复沟通的老本。
4 研发估算
迭代打算会议的重头戏就是确定迭代的工作内容和范畴，即「做什么」和「做多少」。Scrum 团队必须理解本人在每个迭代中曾经实现的工作量，以及下一个迭代须要实现的工作量，能力评估增量交付是否顺利完成。
研发估算蕴含两个方面：团队研发容量的估算和研发速率的测算。
01 团队容量的估算
Scrum 团队的研发容量（Capacity）是团队以后研发能力的直观体现，是掂量团队在迭代期间可能实现多少工作的重要指标，常以过来迭代周期曾经交付的均匀工作量估算，通过「速度 - 工夫」公式即可算出：
研发速率 x 迭代时长 = 交付工作量
也就是说，想要估算团队研发能力就必须晓得团队的研发速率（Velocity），即团队在单个迭代内能够实现的工作量。
速率是 Scrum 中的要害指标，每个团队都应该精确地晓得本人在每个迭代阶段实现了多少工作，并以更麻利的办法打消阻碍，放慢工作速度。通常，咱们习惯 取最近的 3~4 个迭代周期的工作实现量的平均值 作为下一周期的研发速率指标。
02 研发工作量的测算
估算团队容量须要计算团队速率，而团队速率计算则须要统计研发工作量的平均值（禁止套娃）。两种最罕用于研发工作量计算的度量单位别离是工时和点数。
- 工时又称人时，即「人天 / 人时」，是间接反映实现某项工作须要几个人做多长的工夫的指标；
- 故事点数 是实现一个故事所须要付出的绝对工夫的度量单位，须要先选定一个能够作为规范度量单位的需要，并约定其工作量为「1 点」。
麻利实际中，许多团队会应用「麻利扑克」辅助实现需要的故事点数评估；故事点数和工时并行的模式也能更全面地估算研发工作的复杂度和实现时长。
Liga 总结
迭代打算会议须要产品负责人 PO、Scrum Master 和开发团队在迭代指标和迭代待办列表上达成共识，为「做什么」和「怎么做」交出对立答卷。
对立的需要准入和准出规范（DoR 和 DoD）、优先级排序正确的产品待办列表（Product Backlog）、价值传递清晰的用户故事（PBI）和纯熟的需要拆分和研发估算技法，都能帮忙研发团队实现一场高效的迭代打算会议。
理解更多麻利开发、项目管理、行业动态等音讯，关注咱们的 sf 账号 -LigaAI~ 或者点击 LigaAI- 新一代智能研发合作平台，在线申请体验咱们的产品。