sprint-brief

Sprint 简报技能

生成一份清晰、易于浏览的 Sprint 简报，让每位团队成员——工程师、设计师、PM——都能在 3 分钟内读完，并准确理解我们要做什么以及为什么要做。

必需输入

如果用户未提供，请向用户询问：

• Sprint 名称和编号
• Sprint 目标（1–2 句话——如果过于含糊，请指出）
• 工单列表及负责人（或工作内容说明）
• 已知依赖项或阻塞项
• 上一个 Sprint 的结转事项（如有）

流程

1. 阅读 Sprint 目标，并检查其是否具体且可衡量——如果过于含糊，请指出
2. 按主题或功能领域对工单分组
3. 确定关键路径——哪些工单必须完成，才能达成 Sprint 目标？
4. 标记风险：验收标准不明确、缺少设计或依赖项尚未解决的工单
5. 记录结转事项，以及它们是否会影响本 Sprint 的目标
6. 验证——根据工单范围和团队产能，确认 Sprint 目标是否可实现。如果仅关键路径上的事项就会占满整个 Sprint，请指出工作量超负荷。

输出结构

Sprint [Number] 简报 — [Dates]

Sprint 目标：[1–2 句话——具体且可衡量] 本 Sprint 的重要性：[用 2–3 句话说明与季度 OKR 的关联]

本 Sprint 的工作内容：

• [主题 1]：[工单和负责人]
• [主题 2]：[工单和负责人]

关键路径：[其他所有事项都依赖的 2–3 个工单]

需标记的风险：

• [风险 1 + 缓解措施]
• [风险 2 + 缓解措施]

上一个 Sprint 的结转事项：[列出事项 + 对当前目标的影响]

完成定义：[具体且达成共识的 Sprint 成功标准]

深入资料

此技能附带支持文件——如有，请使用：

• references/goal-writing.md——编写能引导行动的 Sprint 目标。生成输出时请参考此文件；其中包含了校准方法和判断要点，而上述方法摘要对此有所精简。
• templates/brief-one-pager.md——带有内嵌质量关卡的可填写交付物模板。当用户想自行编写文档，而不是让系统代为生成时，请提供此模板。

评分标准（0–40）

交付前，先为此技能的任何输出评分；达到 32 分以上即可交付。

维度	0	5	10
目标可评分性	目标是任务清单或含糊的方向（“推进 X”）——到 Sprint 结束时无法评分	目标说明了一个结果，但通过／不通过的标准含糊不清（没有数字、日期或可观察的测试）	目标是单一的结果描述，并且有明确的通过／不通过测试，团队中的任何人在最后一天都能据此评判
关键路径精确度	没有关键路径，或者只说“重要工单”——读者无法判断哪些延误会致命	列出了关键路径工单，但没有排序，也没有说明目标会在哪个日期或触发条件下无法达成	按依赖顺序列出具体工单，说明导致目标无法达成的截止时间，并明确区分会导致目标失败的事项与可承受延误的其他事项
风险可执行性	风险只是令人担忧的事项清单——没有缓解措施，也没有负责人	每项风险都有缓解措施或负责人，但应对方案较笼统（例如“密切关注”）	每项风险都有具体的缓解措施、必须就绪的日期和一名明确负责人，并说明该风险会威胁目标还是仅影响某个工单
产能评估的诚实度	列出了结转事项，却未说明影响；看板超负荷但未明说	说明了结转事项对目标的影响，但简报未采取行动——只将超负荷标记为风险，未进一步处理	将结转事项计入产能，并明确说明解决方式：列出具体的范围缩减项、缩减后的目标，或团队明确同意接受超负荷

质量检查

• Sprint 目标足够具体，能在 Sprint 结束时判定通过或失败
• 明确列出关键路径事项，而不只是说“重要事项”
• 每项风险都有缓解措施或负责人，而不只是说“这是一个风险”
• 说明遗留事项对本次 Sprint 目标的影响
• Definition of Done 是达成一致的标准，而不是任务清单

反模式

• 不要把 Sprint 目标写成任务清单——目标必须是一条以结果为导向、可判定通过或失败的陈述
• 不要让关键路径处于未明确状态——“重要工单”不等于关键路径
• 列出风险时必须同时给出缓解措施或负责人——没有应对措施的风险只是忧虑清单
• 不要忽略遗留事项对本次 Sprint 容量和目标的影响
• 不要在 Definition of Done 中混合任务完成情况和结果标准——这些标准必须可观察，并在 Sprint 开始前达成一致