适用范围：已完成敏捷启动与自管理团队组建、需要进入"按迭代节奏交付"阶段的 Scrum Master、PO 与产研管理者，特别是对迭代计划会议议程、估算方式选择、团队承诺机制有困惑的实践者。
更新摘要（v2 · 2026-08 更新）：在原版迭代计划会议基础上，对齐 Scrum Guide 2020 版 Sprint Planning 三议题（Why/What/How），引入 Sprint Goal 与 Definition of Done 作为强制性承诺的现代实践，补充 2025 年 SEEAgent 多智能体估算框架与 AI 时代故事点失真问题，并加入中国本土化迭代节奏案例。失效图片已替换为 Mermaid 图与文字表格。
经常有人问："敏捷核心是拥抱变化，那为什么要做计划？"这是因为敏捷和所有项目管理都一样，需要行动方案指导达成未来目标，计划帮助团队有序推进。但敏捷的计划频度较传统开发更高频、更灵活，称之为迭代计划（Iteration Plan / Sprint Plan）。
在敏捷中，团队要把上一个迭代中用户的反馈加入本次迭代，形成闭环：演进阶段根据待办事项列表选择优先级最高任务→实施阶段完成任务→反馈阶段收集用户体验→优化阶段根据反馈优化。迭代计划帮助团队高效推进。
Scrum Guide 2020 版明确 Sprint Planning 三议题：为何有价值（Why）、可做什么（What）、如何完成（How）。本文用一篇文章讲清迭代计划会议的完整议程、两种估算方式的选择、团队承诺的建立，并补全 AI 时代的故事点失真与重校准路径。
时间盒是一种管理方法：在预算时间内对完不成的功能进行删减或延迟，而不是拖延预算的时间。一个好的迭代计划应该是在时间盒内尽可能排进价值最高的待办事项。
时间盒的核心逻辑：交付时间固定，范围可变。就像坐高铁，错过时间只能改签到下一列，发版日期交付不了只能等下个发版周期。这种刚性约束倒逼团队学会"按价值排序、低优先级剔除"的优先级管理能力。
制定迭代计划时必须考虑以下方面：
2020 版 Scrum Guide 把 Sprint Planning 议程结构化为三个议题，对应原版的"What 与 How"但更清晰：
| 议题 | 含义 | 关键产出 |
|---|---|---|
| Why（为何有价值） | 这次 Sprint 为何对利益相关方有价值 | Sprint Goal |
| What（可做什么） | 这次 Sprint 可以完成什么 | 选取的 Product Backlog 项 |
| How（如何完成） | 选定的工作如何完成 | Sprint Backlog + 计划 |
上图揭示 2020 版的关键变化：Sprint Goal 与 Definition of Done 不再可选，分别作为 Sprint Backlog 与 Increment 的承诺。这意味着迭代计划必须明确"为什么做"和"什么算完成"两个底线，不能只关注"做什么"。
迭代计划会议需要考虑以下要素：
| 要素 | 含义 |
|---|---|
| 会议目的 | 明确即将开展的工作内容，讨论明晰待办事项的相关信息 |
| 会议参与人 | SM 是组织者，PO 和跨职能团队均要参与 |
| 会议议程 | 分 What 与 How 两部分（详见 3.2） |
| 确定迭代目标 | 把此目标放在团队显眼处同步 |
| 输出 | 迭代待办事项列表（Sprint Backlog），即待办事项列表中优先级最高的事项子集 |
第一部分 What（明确做什么）
需要换位思考，站在用户角度使用产品，设身处地从场景中提炼用户痛点，这个过程也叫作"讲故事"。
PO 会使用 MoSCoW 法则对任务进行基于客户价值的优先级排序：
| 优先级 | 含义 | 处理原则 |
|---|---|---|
| Must | 必须做——系统基础，没有它们无法 work 或无价值 | 必须完成 |
| Should | 应该做——这样系统才可正常使用，没有它们非常难用 | 应该完成 |
| Could | 可以做——产品的附加值、加分亮点项 | 争取完成，变更时优先牺牲 |
| Won't | 不要做——这个产品不需要的功能 | 不纳入迭代 |
从待办事项列表中选出既能满足用户痛点、同时优先级较高的用户故事，支持用户场景落地。
第二部分 How（明确怎么做）
理想人天数估算（Ideal Days）
故事点数估算（Story Points）
选择建议：
迭代计划会议目标：
讲故事：假设是用户要订房。出差一族平均报销房费 500 元左右，用户使用 APP 时能得到通过地理位置推荐附近价值合适的酒店列表，可以选择房型并发起预订，可以根据确切的酒店位置找到。
用户故事：房型清单、房型详情、下订、填写用户信息、确认房型信息。
定目标：第一个迭代目标是让用户能够在线上选订房间，具体包括房间展示、预订、退订。
故事点数估算结果：
| 用户故事 | 故事点数 |
|---|---|
| 房型清单 | 3 |
| 房型详情 | 2 |
| 下订 | 3 |
| 填写用户信息 | 1 |
| 确认房型信息 | 1 |
分解任务：对每个故事点拆解，分配负责人并让负责人评估自己任务的天数。
团队承诺：公开的承诺非常有效，在公开环境中大家会尽最大努力完成承诺。团队承诺可以是：张三、李四、王五、赵一检查自己的任务是合理适度且自力可成的，并在迭代会议上是否能保质保量完成打上分数（满分 5 分）。
| 阶段 | 工具支撑 | 2025 年代表能力 |
|---|---|---|
| Backlog 选取 | TAPD Backlog 优先级视图 | 价值排序可视化 |
| 估算协作 | Planning Poker 在线工具 | 异地团队同步估算 |
| 任务分解 | TAPD NPC AI 拆任务 | 一句话拆解子任务 |
| 工时估算 | TAPD AI 工时模型推荐 | 复杂度×基准工时 |
| Sprint Goal 同步 | TAPD 看板墙/飞书文档 | 团队显眼处同步 |
| 团队承诺 | TAPD 任务认领+承诺打分 | 公开承诺+回顾打分 |
TAPD 8.0 集成腾讯混元大模型，迭代计划会议可借助 NPC AI 助手：
某游戏团队通过 TAPD AI 报告自动生成，把每周准备迭代评审材料的时间从 4 小时压缩到 20 分钟，让 SM 把精力从"准备材料"转向"促进团队反思"。
| 企业 | 迭代周期 | 关键节奏安排 |
|---|---|---|
| 腾讯欢乐斗地主手游 | 1-2 周 | 持续集成 SODA 自动编译/测试/部署 |
| 一汽红旗 | 2 周 | 早 9 点需求冻结规则 |
| 蔚来汽车 | 软件分层解耦后并行迭代 | OS-平台服务-应用三层模型 |
| 科大讯飞智汽 | SAFe ART 同步节奏 | 每周 SoS 会议同步依赖 |
| 福建海峡银行 | 增量交付+合规文档 | 文档与功能同步完成 |
误区 1：把 Sprint Goal 当 KPI。Sprint Goal 是 Sprint Backlog 的承诺，给团队迭代焦点，不是 KPI。把它当 KPI 会催生"为达成 Goal 而忽略质量"的副作用。2020 版 Scrum Guide 同时把 Definition of Done 作为强制承诺，正是为了平衡这一点。
误区 2：忽视 Definition of Done。2020 版 Scrum Guide 把 DoD 列为 Increment 的强制承诺。如果团队没有明确的 DoD，"完成"的标准模糊，团队成员对"是否完成"理解不一，质量难以保证。
误区 3：估算方式一刀切。刚接触敏捷的团队用理想人天估算更简单，运用敏捷一年以上的团队用故事点估算更准确。一刀切会要么增加估算负担、要么失去估算精度。
误区 4：估算只求数字不求共识。估算扑克的本质不是求平均，而是让每人发言、达成共识。如果团队估算差距大却不陈述理由，估算就失去意义。
误区 5：迭代内频繁发布打乱节奏。如有紧急需求可在迭代内发布，但一般不超过 2 个。迭代内太多次发布，整个节奏就会乱掉，迭代节奏也就没有意义了。
误区 6：照搬他司迭代周期。腾讯欢乐斗地主用 1-2 周，一汽红旗用 2 周，蔚来用并行迭代。迭代周期取决于团队敏捷成熟度与自动化程度，没有"标准答案"，要根据自身情况裁剪。
GitHub 2023 年调研显示，68% 引入 AI 工具的团队遇到故事点估算失效问题。具体表现：
应对策略——分离"编码工作量"与"交付工作量"：
| 阶段 | AI 影响 | 估算调整 |
|---|---|---|
| 理解需求 | 极小 | 保留原估算 |
| 写代码 | 高（2-10 倍提速） | 单独估算编码工作量 |
| 代码评审 | 负面（更多代码待评审、质量更低） | 评审工作量上调 |
| 测试 | 中等（AI 可生成测试但需验证） | 验证工作量保留 |
| 集成部署 | 极小 | 保留原估算 |
如果团队估算主要基于编码时间，故事点已严重失真；如果估算基于总交付工作量，则相对准确。建议团队用 2-3 个 Sprint 重新校准参考故事（Reference Stories），重新评估 5-10 个已完成故事，差距会显示校准方向。
2025 年 9 月 arXiv 论文 SEEAgent 提出基于 LLM 的多智能体敏捷估算框架，用"长期记忆+短期记忆+行动通信模块"实现可解释、可讨论的估算：
4907 个用户故事验证表明 SEEAgent 在多数指标上超过 Deep-SE 等 SOTA 模型，83% 从业者认为协作自然。这预示着传统估算扑克可能演化为"人+AI 共同估算"的混合模式——保留团队共识机制，但用 AI 提供数据支撑与解释能力。
第一，先定 Sprint Goal 再选 Backlog 项。2020 版 Scrum Guide 把 Sprint Goal 列为 Sprint Backlog 的强制承诺，意味着迭代计划必须先回答"为何有价值"，再决定"做什么"。如果直接从 Backlog 选项开始，容易陷入"无目标堆叠任务"陷阱。
第二，Definition of Done 必须明确且团队共识。2020 版 Scrum Guide 把 DoD 列为 Increment 的强制承诺。如果团队对"什么算完成"没有共识，"完成"的标准模糊，质量难以保证。建议团队在迭代计划会议开始前花 10 分钟共审 DoD。
第三，预留 AI 化估算升级路径。即便当下不接入 AI 估算，也要在历史数据沉淀、知识库建设、需求结构化上预留升级空间。TAPD 8.0 的 NPC AI 助手已能基于历史数据推荐工时模型（如复杂度高任务=基准工时×1.5），团队在选型时也要评估工具的 AI 化演进路径。
下一篇：08-执行和监控：如何使团队进展“透明化”？（v2） 将讲解执行与监控阶段的职责边界、每日站会与白板三区结构，让团队进展真正"透明化"。