产品经理课程 · 第三阶段：项目管理
📅 12 - Sprint规划
容量规划+任务拆解+承诺
📋 本章导读
Sprint规划是把"要做什么"变成"这个迭代做什么"的关键环节。好的Sprint规划让团队有清晰目标、合理节奏和交付信心。本章将从容量规划出发，教你做任务拆解和Sprint承诺。
🎯 学习目标
- 掌握团队容量计算和Sprint容量规划
- 学会用户故事拆解到任务的实操方法
- 理解Sprint承诺的原则和沟通技巧
- 能独立主持Sprint规划会议
一、容量规划：你知道团队真正能做多少吗？
过度承诺是Sprint失败的头号原因。容量规划用数据替代猜测。
📊 容量计算方法
Sprint容量 = 团队人数 × Sprint天数 × 可用率 × 专注率
示例（2周Sprint，5人团队）：
总天数 = 5人 × 10天 = 50人天
减去假期 = -3天（1人请假）= 47人天
可用率 = 80%（会议、沟通、代码review等）
专注率 = 70%（减少上下文切换）
有效容量 = 47 × 0.8 × 0.7 ≈ 26人天
历史速率(velocity)参考：
过去3个Sprint平均完成25-28点
本Sprint目标：26点（取中间值）
⚠️ 容量规划常见错误：把"10人天"等同于"1个人10天"。任务并行度、依赖关系、上下文切换成本都会影响实际产出。用历史速率而非理论计算来校准容量。
二、任务拆解：从故事到可执行的工作
用户故事是"做什么"，任务是"怎么做"。好的任务拆解让每个人清楚自己要干什么。
📋 故事拆解模板
用户故事：作为用户，我可以用手机号注册账号
验收标准：
✓ 输入手机号→发送验证码→输入验证码→设置密码→注册成功
✓ 验证码60秒有效期，可重新发送
✓ 手机号已注册→提示"该手机号已注册，是否登录？"
✓ 密码8-20位，必须包含字母和数字
任务拆解：
T1：手机号输入框+格式校验（前端，2h）
T2：验证码发送接口+频率限制（后端，4h）
T3：验证码输入框+倒计时（前端，2h）
T4：验证码校验接口（后端，3h）
T5：密码设置+强度校验（前端，3h）
T6：注册接口+数据写入（后端，4h）
T7：异常处理（已注册/验证码过期/格式错误）（前后端，3h）
T8：联调+自测（2h）
总计：23h ≈ 3人天
🔑 拆解原则
- 每个任务≤1天：超过1天的任务说明还不够具体，继续拆
- 任务有明确产出：每个任务完成时有可验证的产出（代码/文档/测试）
- 标注依赖关系：T4依赖T2，T7依赖T5和T6——依赖链决定并行度
- 留buffer：总估算×1.2作为缓冲，未知风险总要预留
三、Sprint承诺：科学的承诺vs拍脑袋
❌ 拍脑袋承诺
- "老板说这个必须做完"
- "我们加加班应该能搞定"
- "先承诺了再说，做不完再砍"
- 结果：Sprint结束只完成60%，团队疲惫，信任崩塌
✅ 科学承诺
- 基于历史速率（过去3个Sprint平均完成26点）
- 基于当前容量（2人请假，容量减少20%）
- 留10-20%buffer处理突发事件
- 承诺=Sprint Goal而非功能列表
四、Sprint Goal：让团队有方向感
Sprint Goal是一句话描述本迭代的交付价值——不是功能列表，而是用户价值。
🎯 好的Sprint Goal
- ❌ "完成注册、登录、个人中心"（功能列表）
- ✅ "新用户能在3分钟内完成注册并首次使用核心功能"（价值描述）
- ❌ "优化性能"（太模糊）
- ✅ "首页加载时间从3秒降到1秒以内"（可衡量）
五、案例深度拆解：Stripe的Sprint规划
💳 Stripe：支付基础设施的精确迭代
Stripe作为全球支付基础设施，Sprint规划的精确度直接影响到数百万商家的资金流转。
- 容量可视化：每个Sprint开始前，公开团队日历（请假/会议/On-call），让承诺基于事实
- 风险前置：每个故事标注"技术风险"和"产品风险"，高风险的优先做
- 0.5点故事：引入半点估算，避免所有小任务都标1点导致总量虚高
- Sprint Goal必须关联业务指标：不是"做XX功能"，而是"提升XX转化率"
💡 Stripe的做法：Sprint承诺后，如果遇到超过2天的新增工作，必须做Sprint范围调整而非默默加进去。透明比完美更重要。
🧪 练习1：容量计算
假设你的团队有6人，2周Sprint，1人请3天假，1人有2天On-call。过去3个Sprint完成28/25/30点。计算本Sprint的有效容量和承诺点数。
🧪 练习2：故事拆解
拆解以下用户故事为任务："作为用户，我可以在App内邀请朋友加入群组"。包含：验收标准、任务列表（每个≤1天）、依赖关系、总估算。
🧪 练习3：Sprint Goal制定
为你的产品制定下个Sprint的Goal，确保它：1）描述用户价值而非功能列表 2）可衡量 3）团队有信心完成。
🏆 本章成就
- ✅ 容量规划师 — 用数据和经验精确计算Sprint容量
- ✅ 任务拆解者 — 将故事拆解为可执行、可验证的细粒度任务
- ✅ 科学承诺者 — 基于速率和容量而非压力做承诺
- ✅ 方向引导者 — 用Sprint Goal让团队聚焦价值交付
六、Sprint规划会议主持指南
📋 高效Sprint规划会的7步流程
- 回顾上Sprint（10分钟）：完成率、遗留项、速率数据
- 确认Sprint容量（5分钟）：请假、On-call、技术债分配
- PM讲解高优先级故事（20分钟）：每个故事的背景、验收标准、依赖
- 团队提问和讨论（15分钟）：技术方案、边界条件、风险
- 估算故事点（15分钟）：规划扑克或T-shirt估算
- 确认Sprint Backlog（10分钟）：选入的故事+总点数+确认Goal
- 确认承诺（5分钟）：每个人口头确认"我有信心完成"
📚 Sprint规划推荐阅读
- 《Agile Estimating and Planning》Mike Cohn — Sprint规划的系统方法
- 《Sprint》Jake Knapp — 设计冲刺方法论
- 《The Principles of Product Development Flow》strong>Reinertsen — 产品开发流的理论基础
💡 Sprint规划的核心心法：规划会的产出不是"一张任务列表"，而是"团队对目标的共识"。如果规划会后还有人不知道这个Sprint最重要的1件事是什么，规划会就是失败的。
七、Sprint规划中的常见陷阱
⚠️ 8个Sprint规划陷阱
- 范围蔓延：Sprint中途加需求——每个新增需求必须替换一个等量的现有需求
- 低估依赖：A等B、B等C——依赖链让并行变串行，容量直接打折
- 忽略技术债：只排功能不排技术改进——技术债利滚利，最终拖垮整个系统
- 规划过多：把Sprint塞满100%——留20%buffer给突发事件和探索
- 没有Sprint Goal：只列任务没有目标——团队失去方向感
- PM缺席：PM不参加规划会——需求理解偏差直接导致返工
- 估算不参与：PM替团队估算——必须让做的人估算
- 不回顾速率：不看历史数据——凭感觉承诺必然过度
八、分布式团队的Sprint规划
🌍 远程Sprint规划最佳实践
- 异步准备：规划会前24小时，PM把所有用户故事和验收标准发到团队频道，让每个人提前阅读和提问
- 同步决策：规划会只做决策和估算——"这个做不做？做多少点？"——不在会上读PRD
- 虚拟白板：用Miro/FigJam做可视化的Sprint看板——比列表更直观
- 时区轮换：跨时区团队轮流迁就对方时间——不要总是同一批人加班开会
- 会后确认：规划结论写文档发全团队——异步的人也能看到
📋 Sprint规划的5个产出物
- Sprint Goal：一句话描述本迭代交付的价值
- Sprint Backlog：选入的用户故事+故事点
- 任务拆解：每个故事的技术任务（每个≤1天）
- 容量确认：团队有效容量 vs 承诺点数
- 风险清单：本Sprint的主要风险和应对方案
🎯 Sprint规划的时间分配建议
2周Sprint的规划会不应超过4小时。时间分配：回顾10%、容量确认5%、需求讲解30%、提问讨论20%、估算15%、确认和承诺10%、风险讨论10%。如果超时，说明需求准备不足——应该推迟Sprint开始而非压缩规划质量。
💡 Sprint规划小贴士：如果规划会经常超时，试试"沉默规划"——前20分钟每个人默默写自己的估算和问题，然后集中讨论。这比轮流发言效率高30%，因为避免了"锚定效应"（第一个说话的人影响其他人）。
💡 规划效率：规划会的效率直接决定Sprint的起步速度。养成"会前准备、会中决策、会后确认"的习惯，让你的规划会成为团队最高效的会议。