准备冲刺规划时：估算团队容量、选择故事、梳理依赖并识别风险

在准备 sprint planning、估算团队容量、选择用户故事、平衡冲刺范围与 velocity 时，生成可提交的 sprint 计划。

适用场景

解决思路

1. 读取用户提供的内容：如果用户提供 backlog、velocity 数据、团队名册或上一冲刺报告等文件，先读取这些文件。
2. 估算团队容量：统计团队成员数量及其可用性（PTO、会议、on-call）。
3. 估算团队容量：使用历史 velocity，即最近 3 个 sprint 的平均 story points。
4. 估算团队容量：预留 15-20% 容量缓冲，用于意外工作、bug 和技术债。
5. 估算团队容量：以 story points 或理想小时计算可用容量。
6. 审查并选择故事：从已排序的 backlog 中拉取，按最高优先级优先。
7. 审查并选择故事：验证每个故事满足 Definition of Ready（清晰的 AC、已估算、无阻塞）。
8. 审查并选择故事：标记在提交前仍需 refinement 的故事。
9. 审查并选择故事：达到容量后停止添加故事。
10. 映射依赖关系：识别依赖其他故事或外部团队的故事。
11. 映射依赖关系：为有依赖的故事合理安排顺序。
12. 映射依赖关系：标记外部依赖及其 owner。
13. 映射依赖关系：识别关键路径。
14. 识别风险与缓解措施：找出高不确定性或高复杂度的故事。
15. 识别风险与缓解措施：找出可能延期的外部依赖。
16. 识别风险与缓解措施：找出知识集中风险（只有一个人能做）。
17. 识别风险与缓解措施：为每个风险提出缓解措施。
18. 创建 sprint 计划摘要，使用以下模板： Sprint Goal: [一句话描述成功的样子] Duration: [2 weeks / 1 week / 等] Team Capacity: [X story points] Committed Stories: [Y story points across Z stories] Buffer: [remaining capacity] Stories: 1. [Story title] — [points] — [owner] — [dependencies] ... Risks: - [Risk] → [Mitigation]
19. 定义 sprint goal：用一句清晰的话捕捉该 sprint 的主要价值交付。
20. 逐步思考，并保存为 markdown。

适用边界 · 注意事项

• 团队不使用迭代式 sprint、没有 backlog 或历史 velocity 数据时，容量估算和故事选择会失去依据。
• 只需要规划个人任务、长期路线图或非软件交付项目时。
• sprint 范围已被硬性锁定且完全不可调整时，故事选择、依赖排序和风险缓解的调整空间有限。