需要规划新冲刺、按团队可用性排 backlog 并确定…

适用于启动新冲刺、估算团队容量、决定优先级和处理上一冲刺遗留项的场景。

适用场景

解决思路

1. 使用 /sprint-planning $ARGUMENTS 调用冲刺规划流程。
2. 遇到不熟悉的占位符或需要检查已连接工具时，查看 CONNECTORS.md。
3. 定义冲刺目标和成功标准（用一句话描述成功是什么样）。
4. 估算团队容量，计算时纳入 PTO、会议、on-call 等不可用时间。
5. 对 backlog 事项进行范围界定并排序优先级。
6. 识别依赖和风险。
7. 生成冲刺计划文档。
8. 若连接项目跟踪器：拉取 backlog、创建 sprint、分配事项。
9. 若连接日历：在容量计算中纳入 PTO 和会议。
10. 若连接聊天：把冲刺计划分享给团队。
11. 向团队/相关方收集：团队成员及本冲刺可用性。
12. 确认冲刺长度（天数/周数）。
13. 获取已排序 backlog：从跟踪器拉取、粘贴或由对方描述。
14. 确认上个冲刺是否有未完成项（carryover）。
15. 确认是否有依赖其他团队或被阻塞的事项。
16. 在计划文档中写明冲刺名称、起止日期、团队工程师人数。
17. 写一句清晰的 Sprint Goal。
18. 制作容量表：每人可用天数（X of Y）、分配（点数/小时）、备注（PTO、on-call 等），并汇总总容量。
19. 制作 Sprint Backlog 表：优先级（P0=必须交付、P1=应该交付、P2=弹性/Stretch）、事项、估算、负责人、依赖。
20. 计算并写明计划容量、冲刺负载（点数）以及负载占容量的百分比。
21. 制作风险表：风险、影响、缓解措施。
22. 定义 Definition of Done：代码已评审并合并、测试通过、文档已更新（如适用）、产品签收。
23. 列出关键日期：冲刺开始、中期检查、冲刺结束/演示、回顾。
24. 留出缓冲：按团队容量的 70-80% 制定计划，以应对中断。
25. 只设一个清晰的冲刺目标；若无法用一句话表达，说明冲刺不聚焦。
26. 识别弹性事项（stretch items），明确进度慢于预期时要砍掉哪些。
27. 诚实处理 carryover：重新承诺前先理解上一个冲刺未交付的原因。

适用边界 · 注意事项

• 没有明确 backlog 或团队可用性信息时，不要强行生成正式冲刺计划。
• 团队不按 sprint/迭代工作而采用持续流、任务频繁插入时，正式冲刺规划的收益较低。
• 紧急事故响应或高度不确定的探索性 spike 无法合理预估时，不要把它包装成固定交付承诺。