sprint-plan

sprint-plan 概览

sprint-plan 的作用

sprint-plan skill 可以帮你把一份粗糙的 backlog 转成一个现实可执行的 sprint plan。它重点关注 capacity 估算、story 选择、dependency mapping 和风险审查，让你在 sprint 开始前就能判断哪些内容真正放得下。

适用人群

如果你在 Project Management 场景下需要一次快速、结构化的 planning pass，就适合用 sprint-plan：比如 Scrum Master、PM、工程负责人，以及基于 backlog 导出、velocity 笔记、团队日历或上一轮 sprint 数据来工作的 agent。

这个 skill 为什么有用

通用 prompt 往往只会给出一串 stories，却不会检查团队是否真的交付得了。sprint-plan 更适合“决策很重要”的场景：它会先要 capacity、筛掉未就绪的工作，并尽早暴露 blocker。

最佳适用范围与限制

当你已经有一些 planning 输入时，这个 skill 最强，比如优先级、估算和可用性。它不太适合用来做完整的 backlog grooming、roadmap planning，或者在没有 sprint 级约束的情况下拆解详细 task。

如何使用 sprint-plan skill

安装 sprint-plan

使用 npx skills add phuryn/pm-skills --skill sprint-plan 安装 sprint-plan skill。然后先打开 pm-execution/skills/sprint-plan/SKILL.md，因为这里定义了 planning workflow 以及这个 skill 期望接收到的上下文。

需要提供什么

这个 skill 最适合吃“具体的 planning 材料”，而不是一句“帮我计划这个 sprint”。请提供 sprint 时长、团队成员、PTO 或 on-call 覆盖情况、最近的 velocity、已经排好优先级的 backlog、story points 或 effort 说明，以及任何已知 dependency 或风险。

如何写出更好的提示词

一个好的 prompt 会明确告诉模型它在计划哪个 sprint，以及手头有哪些输入。例如：Use sprint-plan to plan Sprint 24 for a 6-person team. Review this backlog, use the last 3 sprints of velocity, subtract PTO days, keep a 20% buffer, and call out any stories not ready for commitment.

建议的工作流程

先把可用的 source files 喂给 skill，然后让它输出 capacity 估算、一个能放得下的 story 列表，以及 dependency/risk 摘要。如果 backlog 很乱，不要一上来就逼它给最终方案，而是先让它把已承诺的 stories 和待 refinement 的候选项分开。

sprint-plan skill 常见问题

sprint-plan 只适合 Scrum 团队吗？

不是。只要你需要一个有容量上限的交付计划，sprint-plan skill 都有用，即使团队并不严格遵循 Scrum ceremony 也一样。它对开放式的 roadmap 工作帮助会小一些。

它和普通 prompt 有什么不同？

普通 prompt 可能也会生成一个看起来合理的 sprint 列表，但 sprint-plan 的设计目标是一次性检查 readiness、capacity、dependencies 和 risk。这让它更适合安装决策：当你需要的是可重复的 planning workflow，而不是一次性的答案时，它会更有价值。

如果我没有 velocity 数据怎么办？

你仍然可以用 sprint-plan，只要提供团队可用时间和一个保守 buffer 就行，但结果会弱一些。如果没有 velocity，尽量给出你能找到的最接近的替代指标，比如最近完成的工作量，并要求 skill 清楚标记不确定性。

它适合新手吗？

适合，只要你能提供 backlog 和基本团队上下文就行。最常见的失败原因不是 skill 太复杂，而是输入不完整。

如何改进 sprint-plan skill

提供更干净的 planning 输入

提升质量最大的办法，是先把 source material 做好。请提供已经排好优先级的 stories，并附上 acceptance criteria、估算、依赖关系和负责人；模糊的 backlog 项会迫使 skill 猜测，最后通常会变成不现实的 plan。

把 capacity 约束说清楚

如果团队有会议、PTO、interrupts 或 on-call 工作，请一开始就说明。sprint-plan 在能把这些约束换算成可用容量时效果最好，而不是默认大家都全时可用。

要求它给出决策，而不只是摘要

第一次输出后，可以让它给出最终的 commitment 列表、一个“未准备好”列表，以及每个被排除项的原因。这样 sprint-plan 的输出会比泛泛的 planning 回顾更可执行。

针对薄弱环节迭代

如果结果过于乐观，就让它提高 buffer，并按风险重新排序 stories。如果结果过于保守，就问它：等依赖解除后，哪些项目可以替换进去。这是让 sprint-plan 最快贴合团队真实交付节奏的方法。