返回模板页

Sprint 计划示例

下面这些案例展示了敏捷团队如何结构化地安排一个 Sprint——从选取故事到追踪容量和定义完成标准。每个案例对应真实的规划场景，可以直接调整格式套用到自己团队的工作流中。

使用这个模板返回模板页
Sprint 计划示例

真实案例

标准 Scrum Sprint 计划

使用场景: Scrum Master 或开发者，规划两周 Sprint

Sprint 目标：完成用户主页功能
故事 1（5pts）：编辑资料表单 — Alice
故事 2（3pts）：上传头像 — Bob
故事 3（2pts）：更新通知偏好 — Alice
故事 4（8pts）：隐私设置页面 — Bob
容量检查：18pts vs. 容量 20pts
完成定义：部署到测试环境，QA 通过验收

这样组织的原因: 在 Sprint 计划中明确写出完成定义，能防止 Sprint 结束时关于故事是否"真的完成"的经典争论——通过单元测试但未经 QA 验证算不算完成。

功能发布 Sprint

使用场景: 产品经理和技术负责人，围绕特定发布规划 Sprint

Sprint 目标：将结账 v2 发布到生产环境
故事 1：游客结账流程（8pts）
故事 2：优惠码输入框（3pts）
故事 3：订单确认邮件改版（5pts）
故事 4：支付错误处理（5pts）
非故事：QA 回归测试套件（8 小时）
上线标准：所有故事完成 + 冒烟测试通过

这样组织的原因: 在 Sprint 计划中加入明确的上线标准，让产品、研发和 QA 就上线前必须满足的条件达成共识——"所有故事完成"本身不够，还需要回归测试跑完。

设计 Sprint 计划

使用场景: UX Lead，把设计工作与研发 Sprint 并排规划

Sprint 目标：完成引导流程 v2 设计稿
设计任务 1：3 个引导页面线框图（2 天）
设计任务 2：用户测试（1 天）
设计任务 3：根据反馈迭代（1 天）
设计任务 4：交付给研发（0.5 天）
与研发同步：每日 15 分钟 Check-in

这样组织的原因: 把设计工作以 Sprint 增量的形式与研发并排规划，创造自然的交接节点——避免设计稿来得太晚、研发无法在同一个 Sprint 内开始实现的情况。

Bug 修复 Sprint

使用场景: 研发团队，专注于清理技术债和 Bug 的迭代

Sprint 目标：P1/P2 Bug 数量减少 50%
Bug 1：移动端登录死循环（3pts）— 开发 A
Bug 2：数据导出超时（5pts）— 开发 B
Bug 3：通知重复发送（2pts）— 开发 A
技术债：迁移认证库（8pts）— 开发 B
缓冲：预留 20% 容量用于临时任务

这样组织的原因: Bug Sprint 预留 20% 容量给临时任务是务实的——Bug 调查过程中经常会发现新的 Bug，计划过满会导致范围蔓延和 Sprint 目标落空。

独立开发者周 Sprint

使用场景: 自由职业者或独立开发者，规划个人一周工作

Sprint 目标：上线落地页并提交到产品目录
任务 1：撰写落地页文案（周一）
任务 2：开发和部署落地页（周二–周三）
任务 3：提交到 5 个产品目录（周四）
任务 4：撰写发布公告（周四–周五）
备选：搭建邮件收集（周五有时间再做）

这样组织的原因: 给个人 Sprint 加一个备选任务，能防止完成主要任务后失去动力——随时有下一件事可以拉进来。

跨职能产品 Sprint

使用场景: 产品团队，设计、研发和 QA 在同一个 Sprint 计划中协作

Sprint 目标：发布付费升级流程
设计：升级弹窗线框图（第 1–2 天）
研发：后端订阅 API（第 1–4 天）
研发：前端升级 UI（第 3–6 天）
QA：测试计划和执行（第 6–8 天）
PM：更新文档并通知 CSM（第 8 天）
上线：第 10 天

这样组织的原因: 明确标注各职能方向的跨职能 Sprint 计划，让交接依赖一目了然——图上直接看出前端研发必须等设计完成才能开始。

使用技巧

  • 先写 Sprint 目标，再选故事——先选故事容易导致目标只是一个列表，而不是一个统一的方向。
  • 永远不要填满 100% 容量；留出 10–20% 给 Bug、中断和必然出现的临时任务。
  • 每个故事分配给一个负责人，而不是两个——共同负责等于没人负责，Sprint 结束时故事就会做到一半。
  • 在第三天而不是第十天回顾 Sprint 计划——早发现超载，才有时间优雅地缩减范围。

在线开始编辑

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。

使用这个模板： /editor/new?template=sprint-planning

使用这个模板