sprint-planning

冲刺规划

概述

冲刺规划技能帮助产品经理和工程负责人将工作组织成高效的冲刺，在交付与质量之间取得平衡。内容涵盖目标设定、容量规划、故事估算和回顾分析，以实现持续改进。

何时使用此技能

• 规划为期 2 周或 1 周的冲刺
• 估算功能的复杂度和工作量
• 平衡功能开发与技术债务
• 制定切实可行的冲刺承诺
• 开展高效的冲刺启动会
• 开展富有成效的回顾会议
• 提升团队速度并改进流程

冲刺规划框架

规划前准备（提前 1 周）

步骤 1：梳理待办事项

• 检查待办事项中的前 20 项
• 确保事项具有明确的验收标准
• 与 PM 澄清任何含糊的需求
• 将大型事项拆分为 2-4 点的故事
• 标记依赖项和阻碍因素
• 更新优先级顺序

步骤 2：容量规划

• 统计可用人天（总天数 - 计划休假天数）
• 考虑会议和其他开销（通常为 20%）
• 计算开发工作的净容量
• 确认有专长领域的团队成员

步骤 3：依赖项审查

• 找出被之前冲刺阻塞的事项
• 确保优先安排解除阻塞的工作
• 标记外部依赖项（设计、第三方）
• 为外部延误制定应对方案

---

故事点估算

估算框架（斐波那契数列）

故事点表示相对复杂度/工作量，而非小时数

1 point    - Trivial changes: typo fixes, simple config updates
           Example: "Fix button color from blue to red"

2 points   - Simple changes: straightforward feature, 1-2 day effort
           Example: "Add email field to user profile form"

3 points   - Small feature: touches 1-2 components, clear requirements
           Example: "Implement forgot password email flow"

5 points   - Medium feature: crosses multiple systems, some complexity
           Example: "Add two-factor authentication"

8 points   - Complex feature: significant complexity, multiple dependencies
           Example: "Build real-time notification system"

13 points  - Very complex: major feature, high uncertainty
           Example: "Rebuild authentication system"

21 points  - Epic (break down): too large for single sprint
           Example: "Complete mobile app redesign"

估算流程（规划扑克）

步骤 1：介绍故事（2 分钟）

• PM 大声朗读故事
• 澄清验收标准
• 讨论边缘情况和依赖项

步骤 2：静默估算（1-2 分钟）

• 团队成员独立估算
• 使用斐波那契卡片或在线工具
• 暂不讨论

步骤 3：讨论（3-5 分钟）

• 先由高估者发言（“你为什么估算为 8？”）
• 再由低估者发言（“你为什么估算为 3？”）
• 如果存在疑惑，PM 澄清需求
• 团队讨论复杂度/不确定性

步骤 4：重新估算（1 分钟）

• 进行最后一轮估算
• 通常会收敛到一个或两个相邻数字
• 如果仍有较大分歧（1 和 8），则进一步拆分故事

步骤 5：确认（由故事负责人完成）

• 团队达成一致后接受估算
• 记录最终估算值
• 标记需要进一步拆分的故事

估算技巧

避免过高估算：

• 将 1-2 点的故事分配给熟悉同一系统的资深团队成员
• 将未知因素拆分为单独的故事
• 不要因为学习时间而额外加码

避免过低估算：

• 将测试和缺陷修复计入（通常为 20-30%）
• 包含集成工作和代码审查
• 考虑系统复杂度，而不只是顺利流程
• 不要乐观地看待“简单”事项

经常被低估的故事：

• 任何涉及数据库或数据迁移的事项
• 跨浏览器或多平台支持
• 任何有集成要求的事项
• 任何涉及第三方 API 的事项
• 缺陷修复（比功能开发更复杂）

估算锚定：

• 与过去完成的类似故事进行比较
• 参考团队速度趋势（每个冲刺平均完成的点数）
• 如果估算值 > 8 点，则拆分为更小的部分
• 预留估算时间：典型团队会在 2 小时内估算 20-30 个故事

---

冲刺目标定义

目标设定框架

有效的 Sprint 目标应具备以下特点：

• 清晰具体（而非含糊不清）
• 可在单个 Sprint 内完成（而非史诗级任务）
• 体现客户或业务价值（而非仅仅列出任务）
• 能激励团队（与更大的使命相连）
• 可衡量（明确定义完成标准）

Sprint 目标模板：

Sprint 12 目标：“实现实时项目协作”

支持性故事：

1. 实时更新任务状态（8 点）
2. 显示活动动态（5 点）
3. 通知系统 MVP（8 点）
4. WebSocket 基础设施（5 点）
5. 技术债务：升级数据库驱动程序（3 点）

非目标（明确不在范围内）：

• 集成电子邮件通知（计划在 Sprint 13 完成）
• 支持移动设备通知（Sprint 13）
• Slack 集成（Sprint 14）

成功标准：

• 团队交付已承诺点数的 80% 以上
• 功能已达到可投入生产的状态，错误率低于 2%
• 实时更新延迟低于 200 毫秒

这为何重要：

• 减少团队对频繁会议的依赖
• 为改进异步沟通奠定基础
• 预计可提升 8% 的留存率

多团队目标对齐

团队目标 → Sprint 目标 → 计划目标 → 季度目标

**季度目标：**提升团队沟通效率 ├─ 计划 1：实时协作（Sprint 12-13） │ ├─ 团队 A 目标：构建 WebSocket 基础设施 │ ├─ 团队 B 目标：创建活动动态 │ └─ 团队 C 目标：实现通知功能 ├─ 计划 2：移动应用（Sprint 14-15） └─ 计划 3：高级分析（Sprint 16）

---

Sprint 容量规划

团队容量计算

Sprint 总容量（2 周）：

• 团队规模：8 名工程师
• 每位工程师的工作日：10 天（2 周）
• 总人日：80 人日

扣除不可用时间：

• 休假：2 人 × 2 天 = 4 人日
• 会议／培训：1 人 × 2 天 = 2 人日
• 假日：0 人日
• 可用人日：80 - 6 = 74 人日

扣除事务与会议时间：

• 每日站会：15 分钟 × 10 天 × 8 人 = 2 人日
• Sprint 规划：4 小时 = 0.5 人日
• Sprint 评审／回顾：3 小时 = 0.375 人日
• 一对一会议及行政事务：1 小时／周 × 8 人 = 1.6 人日
• 会议／事务总计：约 4.5 人日

净开发容量：74 - 4.5 = 69.5 人日

可用点数（基于速度）：

• 历史速度：每个 Sprint 120 点（过去 4 个 Sprint）
• 根据当前容量调整：120 × (69.5/74) = 目标 112 点

平衡工作分配

建议分配：

• 功能故事：85 点（76%）
• Bug 修复：15 点（13%）
• 技术债务：12 点（11%）
• 承诺总计：112 点

按团队／重点领域划分：

• 后端：40 点（35%）
• 前端：35 点（31%）
• 移动端：20 点（18%）
• QA／基础设施：17 点（15%）

缓冲与应急安排

保守估算（90% 置信度）：

• 承诺点数：85（容量的 75%）
• 缓冲：27 点（容量的 25%）
• 缓冲用于：Bug、计划外工作、机会

中等估算（75% 置信度）：

• 承诺点数：112（容量的 100%）
• 要求：执行完美，没有重大阻碍

激进估算（50% 置信度）：

• 承诺点数：130+（超过容量的 100%）
• 导致：Sprint 无法完成，团队精疲力竭（应避免）

**建议：**每个 Sprint 承诺 85-95 点（容量的 75-85%）

---

Sprint 规划会议结构

Sprint 规划会议议程（2 周 Sprint，共 4 小时）

第 1 部分：背景与目标设定（30 分钟）

“本次 Sprint 要完成什么？为什么？”

• 产品经理介绍优先级最高的事项
• 说明影响优先级的客户反馈背景
• 本次 Sprint 的业务目标
• 需要注意的依赖项和阻碍
• 团队提出澄清问题

**第 2 部分：用户故事细化与估算（2 小时）

“工作有多复杂？完成后会是什么样？”

• PM 按优先级顺序介绍用户故事
• 工程团队讨论技术方案
• 使用计划扑克法进行估算（通常每小时 30-40 个用户故事）
• 拆分超过 8 个点的用户故事
• 识别依赖项和风险

第 3 部分：产能规划与承诺（45 分钟）

“我们实际能承诺完成什么？”

• Scrum Master 介绍可用产能
• 团队考虑估算结果
• 决定将哪些事项纳入 Sprint
• 承诺的总点数应占产能的 75-85%
• 明确记录哪些事项不做及其原因

第 4 部分：Sprint 规划与启动（45 分钟）

“我们将如何执行？谁负责什么？”

• 讨论主要事项的技术方案
• 确定每个用户故事的牵头人
• 规划结对编程或知识共享
• 澄清任何尚未确定的验收标准
• 确认 Sprint 目标
• 制定成功标准和指标

Sprint 规划检查清单

• 产品经理已确定待办事项的优先级
• 待办事项均有验收标准
• 已拆分超过 8 个点的用户故事
• 团队已计算可用产能
• 已考虑休假、会议和管理开销
• 已估算优先级最高的 15-20 个用户故事
• 已明确定义 Sprint 目标
• 团队已承诺完成本次 Sprint 的工作（非强制）
• 已就成功指标达成一致
• 已识别依赖项并制定计划
• 已标记风险并制定缓解计划
• 所有团队成员都理解目标和分工

---

Daily Standup 管理

Standup 形式（15 分钟，限时）

每个人回答以下三个问题：

1. “我昨天完成了什么？”
2. “我今天要完成什么？”
3. “我遇到了哪些阻碍？”

示例：

• 开发人员 A：“完成了用户身份验证用户故事（3 个点）。今天：开始做密码重置。没有阻碍。”
• 开发人员 B：“进行了代码审查并修复了一些小问题。今天：编写密码重置测试。正在等待数据库架构（阻碍）。”
• QA：“测试了身份验证流程。今天：测试边界情况。需要密码重置功能准备就绪。”

Standup 纪律：

• 每天在同一时间进行（保持一致）
• 限时 15 分钟（专注讨论）
• 站立进行（保持活力和专注）
• 汇报 Sprint 承诺事项的进展
• 记录阻碍并跟进

阻碍解决

阻碍类型：

• 依赖其他团队
• 技术阻碍（需求不明确，需要做出架构决策）
• 资源阻碍（等待代码审查、基础设施）
• 外部阻碍（第三方服务、等待客户回复）

阻碍升级：

• 在 Standup 中提出
• Scrum Master 立即跟进
• 尽可能在下次 Standup 前解决
• 如果阻碍将持续超过 1 天，则重新分配工作
• 不要让团队陷入阻塞

---

Sprint 指标与跟踪

关键冲刺指标

速度（每个冲刺完成的点数）

• 定义：冲刺结束时标记为“已完成”的故事点数
• 计算：已完成事项的故事点数总和
• 跟踪：最近 4-6 个冲刺的趋势线
• 速度稳定：能很好地预测未来冲刺
• 速度上升：效率提高或工作更容易
• 速度下降：面临挑战，技术债务不断累积

燃尽图（随时间变化的剩余工作量）

Sprint Points Remaining
120 |
    | ● (Sprint start)
100 | \●
    |  \●
80  |   \●●
    |    \   ●
60  |     \●
    |      \
40  |       ●\
    |        \●
20  |         \●
    |          \●
0   |___________●●___→
    0  2  4  6  8  10  Days
      (ideal line shown)

• 斜率 = 速度
• 隆起 = 冲刺中途新增的工作（尽量避免）
• 平坦区 = 没有进展的日期（需要调查）
• 趋势应在第 10 天前逐步下降至零

范围蔓延（冲刺中途增加或移除的点数）

• 目标：0（冲刺中途不做更改）
• 可接受：低于已承诺点数的 5%
• 不理想：高于已承诺点数的 10%（范围未得到保护）

缺陷逃逸率（冲刺结束后发现的 Bug）

• 定义：需要后续修复的故事所占百分比
• 目标：低于 10%
• 比率高：存在质量问题（应投入资源进行测试）
• 比率低：QA 流程良好

燃尽图解读

健康的冲刺（燃尽进度符合预期）：

• 持续稳步下降
• 范围更改极少
• 在冲刺结束时完成
• 团队对预测有信心

范围蔓延的冲刺（燃尽进度逐渐停滞）：

• 整个冲刺期间不断增加工作
• 燃尽图看起来停滞不前
• 团队承诺过多或总是被动应对
• 行动：停止增加工作，审查承诺流程

质量问题冲刺（燃尽图突然回升）：

• 阻塞项或发现的 Bug 激增
• 发现意料之外的返工
• 需要在回顾会议中调查
• 行动：减少承诺，投入资源进行 QA

受阻的冲刺（燃尽图平坦）：

• 团队被阻塞项困住
• 等待依赖项解决
• 工作没有进展
• 行动：立即处理阻塞项，重新分配工作

---

冲刺评审与回顾

冲刺评审（30-45 分钟）

“我们完成了什么？客户将看到什么？”

议程：

1. 回顾背景和冲刺目标（2 分钟）
2. 演示已完成的工作（20 分钟）
   • 展示可运行的功能
   • 在预发布环境或生产环境中进行现场演示
   • 收集利益相关者的反馈
3. 讨论未完成的工作（5 分钟）
   • 为什么没有完成？
   • 是否会延续到下一个冲刺？
4. 反馈与问答（10 分钟）
   • 客户和利益相关者的反馈
   • 功能请求
   • 对未来工作的方向性反馈

演示最佳实践：

• 提前准备演示
• 展示真实数据，而不是演示数据
• 展示边缘情况和错误处理
• 准备演示失败时的备用方案
• 解释“为什么”，而不只是“是什么”

冲刺回顾（45-60 分钟）

“哪些方面进展顺利？我们可以改进什么？”

三个主要问题：

1. “这个冲刺有哪些方面进展顺利？”
2. “哪些方面可以改进？”
3. “下一个冲刺我们承诺尝试什么？”

回顾形式选项：

标准形式（45 分钟）：

• 热身/破冰（5 分钟）
• 头脑风暴：进展顺利的方面（5 分钟）
• 头脑风暴：需要改进的方面（5 分钟）
• 投票选出优先问题（5 分钟）
• 讨论排名前 2-3 的问题（20 分钟）
• 制定行动和承诺（5 分钟）

帆船形式（35 分钟）：

Wind (what's moving us forward)
    ▲
    | ✓ Clear requirements
    | ✓ Good pairing
Anchor (what's slowing us)
    | ✗ Slow builds
    | ✗ Meetings interrupting focus
Rocks (what could sink us)
    | ⚠ Tech debt accumulation

开始-停止-继续形式（30 分钟）：

• 开始：采用新的实践
• 停止：停止不再适用的实践
• 继续：保持良好的实践

回顾行动与承诺

行动项应当：

• 具体：“为 API 端点实现自动化测试”（而不是“改进测试”）
• 可衡量：“将构建时间从 8 分钟缩短至低于 3 分钟”（而不是“加快构建”）
• 负责人：指定具体个人或搭档
• 时间安排：在冲刺中期检查点前完成
• 跟踪：在下次回顾中检查

行动示例：

• “在冲刺中期前设置代码负责人评审”（负责人：技术负责人）
• “记录 API 集成模式”（负责人：前端负责人）
• “每天安排上午 9-11 点的专注时间”（全团队承诺）
• “站会期间限制使用 Slack”（团队承诺）

回顾指标：

• 团队每个冲刺确定 3-5 个改进领域
• 上一个冲刺的行动项完成率达到 60% 或以上
• 团队士气呈上升趋势或保持稳定
• 速度稳定或有所提高

---

Sprint 规划清单

• 整理并确定待办事项的优先级
• 估算优先级最高的 20 个事项
• 计算团队产能
• 拆分估算值超过 8 点的用户故事
• 定义并统一 Sprint 目标
• 将用户故事分配给团队成员
• 确认依赖关系和阻碍因素
• 明确成功指标和验收标准
• 在 JIRA/跟踪系统中填写用户故事描述
• 团队对承诺有信心（信心度：8/10）
• 完成 Sprint 启动会议
• 设置并准备好燃尽图
• 安排每日站会时间
• 安排 Sprint 评审和回顾会议

交付成果

1. Sprint 计划 - 目标、承诺完成的用户故事、产能计划
2. 用户故事估算 - 拆分并估算所有 Sprint 事项
3. 产能分析 - 可用产能与承诺量的对比
4. 燃尽图仪表板 - 每日跟踪 Sprint 进度
5. 风险登记表 - Sprint 的阻碍因素及缓解措施
6. 团队承诺 - 个人任务分配和目标
7. 成功指标 - 衡量 Sprint 成功与否的方式
8. 回顾行动项 - 记录改进措施和承诺
9. 速率趋势 - 用于预测的历史数据