Iteration Planner

---
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 原则：

| 原则 | 含义 | 检查点 |
|------|------|--------|
| **I**ndependent | 独立 | 是否可单独交付？ |
| **N**egotiable | 可协商 | 实现方式是否灵活？ |
| **V**aluable | 有价值 | 是否对用户有明确价值？ |
| **E**stimable | 可估算 | 团队是否能给出估点？ |
| **S**mall | 小 | 是否能在一个 Sprint 内完成？ |
| **T**estable | 可测试 | 验收标准是否明确？ |

### 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) 知识体系