掌握这四个关键技巧，让需求计划「事半功倍」

Scrum 团队在迭代计划会议（Sprint Planning Meeting）中确定迭代目标，商讨并制定迭代待办列表，为后续开发做十全准备。

• 会议第一阶段：产品负责人 PO 依据最新的产品需求列表（Product Backlog），说明本次迭代需要实现的目标，并同 Scrum Master 和开发团队一起讨论实现目标需要完成的需求项目（Product Backlog Item，即 PBI）；
• 会议第二阶段：Scrum Master 和开发团队在 PO 的说明和解释下，确定 PBI 的需求内涵，将需求向下拆解成用户故事和子任务，同时完成故事估算、优先级排序和子任务归属等环节，制定所有人认可的迭代待办列表。

迭代计划会议的会议流程大致如下：

1. 明确迭代目标，全员达成共识
2. 共享并讨论影响迭代的重要信息更新
3. 确定最新的团队研发速率
4. 结合假期、会议等，确定团队研发能力
5. 消除影响往迭代进行的敏捷障碍
6. 重新审视 DoD，进行适当更新
7. 确定待完成的 PBI
8. 通过需求拆解、研发估算和任务认领，制定迭代待办列表
9. 明确需求要点，制定故事的验收标准
10. 记录规划中出现的新问题，标记故事间的依赖关系
11. 确认迭代目标和待办列表的共识，会议结束

迭代计划会议结束时，必须保证产品负责人 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-新一代智能研发协作平台，在线申请体验我们的产品。