---

name: iteration-planner description: "敏捷 Sprint 规划助手，基于团队产能和历史 Velocity 完成 Sprint 范围选定、任务拆分估点、依赖分析和负载均衡分配，输出可执行的 Sprint 计划。当用户需要进行 Sprint Planning、迭代规划、分配 Story 或 Task、检查负载均衡、分析依赖关系或计算团队产能时触发。不适用于 Sprint 回顾、站会、项目周报或通用任务管理场景。" license: MIT

Sprint Planner — 敏捷 Sprint 规划

基于团队产能 (Capacity) 和历史 Velocity，帮助 Scrum Master / PM 完成 Sprint 规划：拆分并分配 Story/Task，检查负载均衡，识别依赖关系，输出可执行的 Sprint 计划。

---

SOP 流程总览

Step 1: 收集输入 → Step 2: 计算团队产能 → Step 3: 确定 Sprint 目标与范围
    → Step 4: 任务拆分与估点 → Step 5: 依赖分析 → Step 6: 任务分配与负载均衡
    → Step 7: 输出 Sprint 计划 → Step 8: 风险检查与承诺确认

---

Step 1：收集输入信息

向用户收集以下信息（缺失项需主动询问）：

输入项	说明	示例
Sprint 时长	迭代周期天数	2 周 (10 工作日)
团队成员列表	姓名 + 角色	张三(前端)、李四(后端)、王五(测试)
各成员可用天数	考虑请假、会议、其他项目占用	张三 8 天、李四 10 天、王五 9 天
历史 Velocity	近 3-5 个 Sprint 的完成故事点	[32, 28, 35, 30, 33]
Product Backlog	待规划的 Story 列表（含优先级和估点）	见 Backlog 表
已知依赖	Story 之间的前后置关系	Story-3 依赖 Story-1 完成

信息不足时的默认值

• Sprint 时长未指定 → 默认 2 周 (10 工作日)
• 可用天数未指定 → 默认 Sprint 时长 × 0.8（扣除会议和杂务）
• 历史 Velocity 未知 → 使用本次估点总和的 70% 作为保守目标
• 角色未指定 → 按通用开发者处理

---

Step 2：计算团队产能 (Capacity)

2.1 个人产能计算

个人产能 = 可用天数 × 每日有效工时 × 专注系数

参数	默认值	说明
每日有效工时	6 小时	8 小时工作日扣除会议、休息等
专注系数	0.8	扣除上下文切换、沟通等开销

2.2 团队总产能

团队总产能 (人时) = Σ(各成员个人产能)
团队总产能 (故事点) = 参考 Velocity 取值

2.3 产能计算示例

成员	可用天数	有效工时/天	专注系数	个人产能(人时)
张三	8	6	0.8	38.4
李四	10	6	0.8	48.0
王五	9	6	0.8	43.2
合计				129.6

---

Step 3：确定 Sprint 目标与范围

3.1 Velocity 参考值计算

参考 Velocity = 近 N 个 Sprint Velocity 的平均值
建议取 N = 3~5，剔除明显异常值

计算方式	适用场景	说明
简单平均	团队稳定	mean(近 3-5 个 Sprint)
加权平均	团队近期有变化	近期权重更高
取最小值	保守承诺	min(近 3 个 Sprint)

3.2 范围选定规则

1. 按优先级从高到低排列 Backlog
2. 累加故事点，直到接近但不超过参考 Velocity
3. 如最后一个 Story 加入后超出 Velocity 的 110%，则不纳入
4. 留出 10-15% 的缓冲用于应急和技术债务

---

Step 4：任务拆分与估点

4.1 Story 拆分检查

每个 Story 应满足 INVEST 原则：

原则	含义	检查点
Independent	独立	是否可单独交付？
Negotiable	可协商	实现方式是否灵活？
Valuable	有价值	是否对用户有明确价值？
Estimable	可估算	团队是否能给出估点？
Small	小	是否能在一个 Sprint 内完成？
Testable	可测试	验收标准是否明确？

4.2 估点参考

如用户未提供估点，使用以下对照表辅助估算：

故事点	复杂度	典型工作量
1	极简	几小时内完成，无需讨论
2	简单	半天到一天，方案明确
3	中等偏简	1-2 天，有少量不确定性
5	中等	2-3 天，需要设计和讨论
8	复杂	3-5 天，涉及多个组件
13	很复杂	一周左右，建议拆分
21+	过大	必须拆分后再规划

---

Step 5：依赖分析

5.1 依赖类型

类型	说明	示例
完成-开始 (FS)	A 完成后 B 才能开始	API 开发完成后前端才能联调
开始-开始 (SS)	A 开始后 B 才能开始	数据库设计开始后，后端可同步开发
外部依赖	依赖团队外部的交付	等待第三方 API 文档
技术依赖	依赖技术组件或环境	需要先完成基础框架搭建

5.2 依赖检查流程

1. 列出所有 Story 的前置条件
2. 构建依赖关系图（用列表或矩阵表示）
3. 识别关键路径：找出最长依赖链
4. 标记风险依赖：
   • 外部依赖（不可控）→ 标为高风险
   • 跨成员依赖链 > 3 → 标为中风险
   • 循环依赖 → 必须拆解

5.3 依赖矩阵输出格式

| Story    | 依赖于     | 被依赖于    | 类型 | 风险 |
|----------|-----------|-----------|------|------|
| Story-1  | 无        | Story-3   | -    | 低   |
| Story-2  | 无        | 无        | -    | 低   |
| Story-3  | Story-1   | Story-5   | FS   | 中   |
| Story-4  | 外部API   | Story-5   | 外部 | 高   |
| Story-5  | Story-3,4 | 无        | FS   | 高   |

---

Step 6：任务分配与负载均衡

6.1 分配原则

1. 技能匹配优先：按成员技能和 Story 技术要求匹配
2. 依赖顺序：被依赖的 Story 优先分配，确保不阻塞后续任务
3. 负载均衡：各成员负载偏差不超过 ±20%
4. 避免单点故障：关键 Story 不应只由一人负责

6.2 负载均衡计算

成员负载率 = 分配故事点 / 个人产能(故事点等效) × 100%
团队平均负载率 = 总分配故事点 / 团队总产能(故事点等效) × 100%
负载偏差 = |成员负载率 - 团队平均负载率|

6.3 负载均衡检查规则

检查项	阈值	处理方式
成员负载率 > 100%	超载	必须转移任务给其他成员
成员负载率 > 90%	偏高	警告，无缓冲空间
成员负载率 < 50%	偏低	检查是否可承接更多任务
负载偏差 > 20%	不均衡	重新调整分配
单人承担 > 40% 总故事点	集中度过高	分散风险

6.4 分配调整策略

当出现负载不均衡时，按以下优先级调整：

1. 将低优先级 Story 从高负载成员转移到低负载成员
2. 将技能要求不严格的 Story 重新分配
3. 拆分大 Story 使其可由多人并行
4. 缩减 Sprint 范围（移除最低优先级 Story）

---

Step 7：输出 Sprint 计划

完成以上步骤后，按以下模板输出：

## Sprint 计划：Sprint [编号] ([起止日期])

### Sprint 目标
[用一句话描述本 Sprint 要达成的核心目标]

### 团队产能

| 成员 | 角色 | 可用天数 | 产能(人时) |
|------|------|---------|-----------|

- 团队总产能：X 人时
- 参考 Velocity：X 故事点
- 本次规划：X 故事点 (占 Velocity 的 X%)

### Story 分配

| # | Story | 优先级 | 故事点 | 负责人 | 依赖 | 状态 |
|---|-------|--------|-------|--------|------|------|

### 负载分布

| 成员 | 分配故事点 | 负载率 | 状态 |
|------|-----------|--------|------|

### 依赖关系

[依赖矩阵或依赖链描述]

### 关键路径
[列出最长依赖链及预计完成顺序]

### 风险与备注
- [风险项 1]
- [风险项 2]
- [缓冲和应急方案]

---

Step 8：风险检查与承诺确认

最终检查清单

在输出计划后，逐项确认：

• 总故事点是否在 Velocity 的 80-100% 范围内？
• 每位成员负载率是否在 60-90% 之间？
• 负载偏差是否 ≤ 20%？
• 是否有循环依赖？（不允许）
• 外部依赖是否已标注风险等级？
• 关键路径上的 Story 是否有人负责？
• 是否预留了 10-15% 的缓冲？
• Story 估点是否有超过 13 点的？（建议拆分）
• 是否有成员承担了 40% 以上的总故事点？

常见问题处理

问题	建议
Velocity 数据不足	取保守估计（已知数据最小值的 80%）
团队成员变动	新成员首个 Sprint 按 50% 产能计算
需求不清晰	对不清晰 Story 加 Spike（技术调研），不计入 Velocity
技术债务积压	每个 Sprint 预留 15-20% 产能处理技术债
跨团队依赖	标为外部依赖，提前与相关团队对齐

---

常见误区（规划时必须检查并纠正）

误区	后果	正确做法
把 Velocity 当承诺上限，100% 填满	无缓冲，任何意外导致 Sprint 失败	保留 10-15% 缓冲，承诺 85-90%
用满额工作日算产能，忽略会议和请假	产能虚高，实际交付不达预期	必须用 可用天数 × 6h × 0.8
跳过依赖分析直接分配任务	开发中才发现阻塞，被迫返工	先画依赖矩阵再做分配
大 Story（>13 SP）不拆就排进 Sprint	估点不准、进度不可追踪	超过 13 点必须拆分后再规划
关键路径全部压在一个人身上	单点故障，一人请假整条链断	关键路径任务分散到 2+ 人
新成员按满产能分配	新人上手慢，实际完成远低于预期	新成员首个 Sprint 按 50% 产能

---

参考资料

• Mike Cohn《Agile Estimating and Planning》
• Scrum Guide 2020 (scrumguides.org)
• SAFe (Scaled Agile Framework) — PI Planning 和 Sprint Planning 方法论
• PMI-ACP (Agile Certified Practitioner) 知识体系