完整教程：如何开好 Sprint 计划会？通俗聊聊 Scrum 中最关键的“开工仪式”
在敏捷开发团队，尤其是使用Scrum 框架的团队里，有一个会议特定重要，可以说是每个冲刺（Sprint）的「发令枪」——
它就是 Sprint 计划会（Sprint Planning）。
你可能参加过这样的会：PO 大手一挥，说“这个 Sprint 大家干这些！”；开发团队默默听着，心里却在盘算“这能做完吗？”；Scrum Master 在旁边试图让大家别跑题……
但 Sprint 计划会，真的就应该是这样吗？
不！它应该是团队一起搞清楚“大家要去哪儿”、“我们能走多快”、“我们打算怎么干”的一场高效协作。
今天，我们就用最通俗的语言，帮你彻底搞懂：Sprint计划到底是个啥？怎么做？为啥要做这些？
一、先搞明白：Sprint 计划会到底在干嘛？
简单来说，Sprint计划会的目标就三个：
- 定目标：这个 Sprint 我们要完成什么业务价值？（即 Sprint Goal）
- 选工作：为了实现这个目标，大家打算做哪些用户故事？（形成 Sprint Backlog）
- 做承诺：团队基于自己的能力和时间，承诺这些工作“大家能搞定”。
换句话说：Sprint计划会，就是团队和PO一起，把接下来一个冲刺周期（通常是1~4周）要干的事儿，定清楚、聊明白、达成共识的地方。
开会前要准备啥？）就是二、Sprint计划会，有哪些输入？（也就
现场定的吗？咋还有输入？”就是你可能会问：“这会不
“凭空拍脑袋”的会议，它需要一些**“提前准备好的素材”**，才能开得高效、有质量。就是没错，Sprint计划会不
1. 一份“就绪”的产品待办列表（Product Backlog）
- 那些用户故事已经就是啥叫“就绪”？就足够清晰、可讨论、可拆解、可估算，团队一看就明白要干啥，不用再问东问西。
- 为了保证这一点，团队通常会和PO约定一个叫DoR（Definition of Ready，就绪的定义）的标准，比如：
- 用户故事里有“谁要用、要干啥、为什么要干、做成啥样”；
- 验收条件清晰；
- 已经拆得大小适中，不会太大或太模糊。
✅ 通俗理解：就像做饭前，食材得洗好切好，不能拿块生肉就丢进锅里。
2. 团队的“历史速度”（Velocity）
- 每个团队每个 Sprint 大概能做完多少工作量（通常用“故事点”来衡量），这就是历史速率。
- 它帮助团队和PO理性地预测：“我们这个 Sprint 大概能干多少活？”
- 比如：团队平均一个 Sprint 能完成 30 个故事点，那假设有 150 个点的需求，大致要做 5 个 Sprint。
⚠️ 注意：只有“完成了”的才算数，做到 99% 也不行！
✅ 通俗理解：就像你知道自己平均一个月能读 3 本书，那下个月安排 4 本就得掂量掂量。
3. 团队当前可用于 Sprint 的实际时间
不是“每人每天8小时×人数”那么容易。
你要扣除：
- Sprint计划会本身占用的时间
- 例行的站会、回顾会、Bug修复时间
- 突发情况预留时间（比如线上救火）
剩下的，才是团队真正能用来开发新功能的时间。
✅ 通俗理解：你以为一周工作40小时全都能写代码？别忘了开会、填表、回邮件、救火也占时间！
4. PO 提出的 Sprint 目标
这是 PO 根据产品整体规划，结合当前优先级，提出的一个业务目标，比如：
- “让用户能在一分钟内完成注册”
- “修复支付流程中的关键 Bug，确保转化率提升”
这个目标会作为本次 Sprint 的“北极星”，团队围绕它来选择工作。
✅ 关键点：和团队一起协商、对齐、达成共识的结果。就是目标不是上面压下来的任务，而
三、Sprint计划会，会输出啥？
简单说，就俩东西：
- 团队承诺的 Sprint 目标（大家说：这个目标，我们接了！）
- Sprint Backlog（也就是本次 Sprint 要做的用户故事 + 拆解后的任务清单）
这俩东西，就是团队未来 1~4 周工作的“导航仪”和“施工图”。
四、谁要来参加这个会？
Sprint计划会可不是创建团队自己关起门来开的，它是一个三方协作的会议，缺一不可：
| 角色 | 谁 | 干嘛的 |
|---|---|---|
| 产品负责人（PO） | 业务方代表 | 负责明确目标、排优先级、讲需求、答疑 |
| 开发团队（Developers） | 程序员、测试、UX等 | 估算工作量、选任务、拆任务、承诺目标 |
| Scrum Master | 流程引导者 | 保证会议高效，流程顺畅，帮团队移除障碍 |
✅ 记住：“领导布置任务”的现场。就是这是一场“大家一起商量怎么干”的会议，不
五、Sprint计划会，到底是怎么开的？（流程一步步拆解）
我们来模拟一下这个会议的常见流程，通俗版：
第一步：PO 上台讲目标，说清楚“我们要干啥”
PO 会介绍本次 Sprint 的目标，以及背后对应的用户故事。讲清楚这些：
- Who：谁是用户？
- What：要完成什么功能？
- Why：为什么要做这个？
- How：大致怎么做？
- 验收条件：做到啥程度才算做完？
✅ 目标清晰，团队才有方向感。
第二步：PO 和团队一起澄清需求
团队可能会问：
- 这个特性具体是指？
- 用户在什么场景下用？
- 这个需求的背景是？
- 有没有技术限制或依赖？
这一步常常会细化故事，甚至拆出新的用户故事。
✅ 澄清越充分，后面估算和执行越准。
第三步：团队估算工作量
大家一起评估：做完这个用户故事，大概要花多少时间（通常用“故事点”或“人天”）。
倘若大家对某个故事理解不一致，就再讨论，再估算。
✅ 估算不仅是猜时间，更是对任务复杂度的集体判断。
第四步：团队选任务，组成 Sprint Backlog
根据：
- PO 提的需求优先级
- 团队的速率（能做多少）
- 大家估出来的时间
团队一起讨论，挑出本次 Sprint 打算做的用户故事，形成 Sprint Backlog。
如果挑多了，超出了能力范围，就要和 PO 协商：要么少做点，要么调低目标。
✅ 承诺要理性，不要硬撑！
第五步：把用户故事拆成具体任务
比如一个用户故事是“用户登录”，许可拆成：
- 设计登录页面
- 达成账号校验逻辑
- 做忘记密码特性
- 写登录的测试用例
每个任务尽量控制在1 天以内能搞定，这样方便每天跟踪。
✅ 拆任务时，常常能发现隐藏的技术难点和风险！
干太多了”就是第六步：检查“大家是不
把所有任务的时间加一加，看看会不会超出团队的实际可用时间。
倘若发现“哎呀，干不完了”，就要赶紧调整：删需求、调优先级、或者跟PO重新对齐目标。
✅ 不贪多，能做完才是真的牛。
第七步：团队表态：该 Sprint 目标，我们接不接？
最后，Scrum Master 会问大家：“这个 Sprint 目标，大家有信心完成吗？”
可以用一个方便又有趣的方式：五指拳投票
- 5 指：信心爆棚，绝对能搞定
- 4 指：问题不大
- ✌️ 3 指：有点挑战，但努力下能行
- 2 指：有点悬
- ✊ 1 指：这目标没法做完，不如回家睡觉
如果很多人只伸出 1~2 根手指……那该目标可能要重新聊了。
✅ 承诺不是拍胸脯，而是基于理性的判断与共识。
六、总结：Sprint计划会的核心逻辑
| 关键点 | 一句话总结 |
|---|---|
| 目的 | 明确目标、选定任务、团队承诺 |
| 输入 | 准备好的需求、团队速率、可用时间、PO目标 |
| 输出 | Sprint目标 + Sprint Backlog（任务清单） |
| 谁参与 | PO（业务）、团队（执行）、SM（流程） |
| 成功关键 | 澄清清楚、估算合理、承诺真实、协作透明 |
写在末了：Sprint计划会，不是走形式，而是团队合作的起点
很多团队觉得 Sprint 计划会“没啥用”、“就是定任务”，但其实，它是一次团队对齐目标、共识价值、评估能力、建立承诺的关键协作时刻。
开得好，团队目标清晰、信心满满、执行顺畅；
开得不好，后续全是猜测、误解、加班与救火。
所以，下次开 Sprint 计划会，不妨试试这样问自己：
- 我们的目标真的清晰了吗？
- 每个人都理解要干啥了吗？
- 我们真的只选了“能做完”的工作吗？
- 大家是真心承诺，还是被动接受？
Sprint计划，是每个 Sprint 的起点，也是团队走向成功的第一步。
推荐更多阅读内容
别急着开干！两个让团队少加班的Scrum秘诀
为“做完”和“做好”吵架？——聊聊Scrum中的“完成的定义”（DoD）就是为什么我们团队总
绝不推迟Sprint：Scrum团队必须坚守的底线与深层智慧
项目泥潭中，我找到的不仅是方法论，更是一种“底气”
迭代周期多长才合适？答案不在教科书，而在你的团队
超越规则：让Scrum团队工作协议成为驱动高效协作的“活契约”
如何成为一名卓越的产品负责人？职责、陷阱与五大核心能力
超越流程：以领导力维度，重新定义卓越的Scrum Master
超越会议主持者：深入解读Scrum Master的三个关键维度
浙公网安备 33010602011771号