sprint-velocity-analysis

Sprint 速度分析

分析 Sprint 速度数据，生成一份坦诚的工程团队健康状况报告。目标不是生成看起来乐观的图表，而是揭示交付模式、及早发现功能失调，并为团队及其经理提供可执行的建议。请关注：速度趋势（提升、下降、持平、波动）、故事点估算的一致性、表明长期过度承诺的结转模式，以及与团队产能相关的信号。请生成基于文本的趋势可视化、健康状况诊断，以及包含可衡量目标的具体改进建议。

所需输入

如果用户尚未提供，请询问以下信息：

• Sprint 历史记录 — 每个 Sprint 的名称或编号、承诺的故事点数、已完成的故事点数，以及结转到下一个 Sprint 的事项数；最好至少提供 6–8 个 Sprint 的数据
• 团队规模及其变化 — 当前团队规模，以及数据时间范围内的人员加入或离开情况
• 已知干扰因素 — 影响特定 Sprint 的假期、公司全员会议、值班事故或其他事件
• 周期时间数据（可选） — 如果有，请提供每个 Sprint 的 p50 和 p90 周期时间（从开始到完成所用的时间）
• 完成的定义 — 对于该团队，“已完成”具体指什么（已合并到 main？已部署到生产环境？已获 PO 验收？）

如果未提供周期时间数据，请省略该部分，并将其注明为建议添加的数据来源。

输出格式

---

Sprint 速度分析：[团队名称]

分析周期： Sprint [N] 至 Sprint [N+7]（[日期范围]） 团队规模： [X 名工程师]（[注明期间的任何变化]） 报告日期： [日期] 数据来源： [数据来源，例如 Jira、Linear、电子表格等]

---

速度趋势

原始数据

Sprint	承诺点数	完成点数	完成率	结转项	备注
[Sprint N]	[X 点]	[X 点]	[X%]	[X 点 / X 项]	[干扰因素或背景]
[Sprint N+1]	[X 点]	[X 点]	[X%]	[X 点 / X 项]
[Sprint N+2]	[X 点]	[X 点]	[X%]	[X 点 / X 项]
[Sprint N+3]	[X 点]	[X 点]	[X%]	[X 点 / X 项]
[Sprint N+4]	[X 点]	[X 点]	[X%]	[X 点 / X 项]
[Sprint N+5]	[X 点]	[X 点]	[X%]	[X 点 / X 项]
[Sprint N+6]	[X 点]	[X 点]	[X%]	[X 点 / X 项]
[Sprint N+7]	[X 点]	[X 点]	[X%]	[X 点 / X 项]
平均值	[X 点]	[X 点]	[X%]	[X 点]

速度图表（每个 Sprint 的已完成点数）

Points
  60 |
  55 |          ●
  50 |    ●           ●
  45 | ●        ●          ●
  40 |               ●          ●
  35 |
  30 |
     +--+--+--+--+--+--+--+--
      N N+1 N+2 N+3 N+4 N+5 N+6 N+7
      Sprint

  ● = Completed points   — = Average ([X pts])

请根据提供的实际数据，使用 ASCII 字符生成此图表。Y 轴范围应与数据范围相符。绘制已完成（而非承诺）的点数，并用虚线标出平均值。

趋势诊断

指标	数值	解读
平均速度	[X 点/Sprint]	[规划基准]
速度标准差	[±X 点]	[低于平均值的 15% = 稳定；高于 25% = 波动较大]
趋势方向	[提升 / 持平 / 下降 / 波动较大]	[对比最近 3 个 Sprint 的平均值与最早 3 个 Sprint 的平均值]
平均完成率	[X%]	[健康范围：80–95%；< 75% = 长期过度承诺]
结转率	[每个 Sprint 结转的承诺点数占比为 X%]	[健康范围：< 15%；> 25% = 系统性问题]
完成率 < 75% 的 Sprint 数	[8 个 Sprint 中有 X 个]	[超过 3 个 = 结构性问题，而非随机波动]

---

故事点校准

只有一致地应用故事点，它们才有用。请在数据中查找以下校准信号：

信号	观测结果	解读
团队规模稳定，但速度波动很大	[是 / 否]	表明估算不一致——同样的工作量每周评分不同
持续过度承诺（承诺量 >> 完成量）	[是 / 否 — 每个迭代平均 X 点]	团队在估算时刻意留有余量，或忽略了历史产能
持续承诺不足（完成量比承诺量高出 > 20%）	[是 / 否]	团队在估算中留有过多余量，或频繁加入未计划的工作
经常有大型事项（> 13 点）结转	[是 / 否]	事项过大，无法可靠估算——需要更好地拆分
团队变动后速度骤降	[是 / 否 — Sprint N+X]	团队组成变化后，没有重新设定产能基准

校准结论： [校准良好 / 需要重新校准 / 校准严重失准 — 用一句话结合上述信号说明]

如果需要重新校准： [具体建议——例如：“使用最近完成的 20 个事项开展校准会议，由团队共同重新评分，并用所得相对规模作为未来估算的基准。”]

---

结转模式分析

结转是衡量承诺可靠性问题最可靠的先行指标。

迭代	结转事项	结转事项的常见主题
[Sprint N]	[X 个事项 / X 点]	[技术债务、依赖受阻、范围界定不当等]
[Sprint N+1]	[X 个事项 / X 点]	[主题]
[Sprint N+2]	[X 个事项 / X 点]	[主题]

已确认的结转根本原因：

• [根本原因 1：例如，“12 个结转事项中有 5 个受阻于第三方 API 集成——这是外部依赖问题，而非估算失误”]
• [根本原因 2：例如，“12 个结转事项中有 4 个估算为 8 点以上，后来发现其规模比预期大 2–3 倍”]
• [根本原因 3：例如，“12 个结转事项中有 3 个是值班事故造成的中断，占用了未计划的产能”]

---

产能利用率

迭代	团队规模	可用产能（点）	承诺量	利用率 %	干扰因素
[Sprint N]	[X 名工程师]	[X 点]	[X 点]	[X%]	[假期 / 事故 / 无]
[Sprint N+1]	[X 名工程师]	[X 点]	[X 点]	[X%]

使用的产能计算方式： [X 名工程师 × 每人每个迭代 Y 点 = 可用产能 Z 点。如果团队产能在统计期间内发生变化，请注明哪些迭代采用了哪种团队规模。]

平均利用率： [X%] 利用率解读： [< 70% = 团队工作量不足或估算留有过多余量 | 70–90% = 健康区间 | > 90% = 没有应对未计划工作的余量——较脆弱]

---

健康状况诊断

维度	评分	依据	优先级
交付可预测性	[绿 / 黄 / 红]	[平均完成率 X%，标准差 Y 点]	[高 / 中 / 低]
承诺准确性	[绿 / 黄 / 红]	[团队每个迭代平均过度承诺 X 点]
估算一致性	[绿 / 黄 / 红]	[速度标准差 ±X 点，校准结论]
结转管理	[绿 / 黄 / 红]	[X% 结转率，根本原因]
产能管理	[绿 / 黄 / 红]	[平均利用率 X%，干扰因素处理情况]
趋势方向	[绿 / 黄 / 红]	[最近 3 个迭代的平均值与之前 3 个迭代的平均值对比]

评分指南： 绿 = 处于健康范围内；黄 = 临界，需要密切关注，或属于单个迭代的异常；红 = 长期存在的问题，需要积极干预。

总体健康状况： [绿 / 黄 / 红] — [用一句话概述：“团队每个迭代都能稳定交付 X 点，但长期过度承诺正在损害士气，并让利益相关者对情况产生误判。”]

---

阻塞因素频率分析

如果提供了阻塞因素数据，请完成本节。如果没有，请将其列为建议新增的跟踪项。

阻塞因素类别	频率（最近 8 个冲刺）	平均阻塞天数	影响（延迟的点数）
外部依赖	[X 次]	[X 天]	[X 点]
技术债务 / 返工	[X 次]	[X 天]	[X 点]
需求不明确	[X 次]	[X 天]	[X 点]
值班中断	[X 次]	[X 天]	[X 点]
环境 / 工具	[X 次]	[X 天]	[X 点]

首要待解决的阻塞因素： [指出影响最大的单一阻塞因素类别，以及解决它将如何提升速度。]

---

改进建议

按预期影响从高到低给出 3 条具体建议。每条建议都必须包含可衡量的成功目标和实施步骤。

建议 1：[标题]

要解决的问题： [哪个健康维度为红色或黄色，以及数据显示了什么]

具体做法：

1. [具体行动步骤——明确到技术负责人可以据此分派任务]
2. [下一步]
3. [下一步]

负责人： [技术负责人 / 工程经理 / 整个团队] 开始时间： [本次冲刺 / 下次冲刺 / 2 周内]

可衡量的目标： [例如，“在 3 个冲刺内将结转率降至 15% 以下”或“连续 4 个冲刺的完成率高于 80%”]

如何判断是否有效： [在结果指标改善前需要关注的先行指标——例如，“即使尚未达到目标，结转项也在逐个冲刺减少”]

---

建议 2：[标题]

要解决的问题： [健康维度及相关证据]

具体做法：

1. [步骤]
2. [步骤]
3. [步骤]

负责人： [角色] 开始时间： [时间]

可衡量的目标： [具体指标和时间范围]

如何判断是否有效： [先行指标]

---

建议 3：[标题]

要解决的问题： [健康维度及相关证据]

具体做法：

1. [步骤]
2. [步骤]

负责人： [角色] 开始时间： [时间]

可衡量的目标： [具体指标和时间范围]

如何判断是否有效： [先行指标]

---

下次冲刺容量预测

下次冲刺： [冲刺 N+8] 已知团队规模： [X 名工程师] 已知容量削减因素： [休假：共 X 天，值班轮换：约占用 Y 点非计划容量，等等]

因素	影响
基础容量（历史平均值）	[X 点]
休假 / 计划内缺勤	−[X 点]
值班开销（估算）	−[X 点]
冲刺 [N+7] 的结转项	+[已占用的承诺容量 X 点]
建议的承诺上限	[X 点]

置信度： [高——团队稳定且容量已知 | 中——干扰程度存在一些不确定性 | 低——团队组成不确定]

规划建议： [用一句话说明——例如，“将冲刺 [N+8] 的计划上限设为 X 点。鉴于存在结转项，请优先完成这些事项，再纳入新的工作范围。”]

---

周期时间分布（如果提供了数据）

冲刺	p50 周期时间	p90 周期时间	已完成事项
[冲刺 N]	[X 天]	[X 天]	[X 项]
[平均值]	[X 天]	[X 天]

周期时间解读： [p90 > 2× p50 表明存在一批长期未完成的事项，值得调查。p50 随时间增加，说明吞吐速度正在下降，且与故事点变化无关。]

如果未提供周期时间数据：本次分析未包含周期时间数据。建议在跟踪中加入每个冲刺的 p50 和 p90 周期时间，以便发现仅靠故事点无法揭示的吞吐问题。

质量检查

• 速度图表根据提供的实际数据生成，而非使用通用占位图表
• 趋势诊断明确指出方向（Improving / Flat / Declining / Erratic），并以定量依据（近期平均值与较早期平均值）作为支撑
• 结转工作的根本原因按具体类别列出并标明数量，而非笼统地指出存在结转工作
• 3 条建议均包含明确的负责人、开始日期和附有时间范围的可衡量目标
• 下一次冲刺的容量预测以历史平均值为基准，并扣除已知的具体减项
• 健康状况诊断表使用 Red/Yellow/Green 等级，并在 Evidence 列中列出证据；不得给出缺乏依据的评分
• 如果缺少指标（周期时间、阻塞项日志），报告会明确指出，并建议补充

反模式

• 不要根据占位数据生成速度图表；图表必须反映提供的实际冲刺数据
• 未计算近期平均值与较早期平均值前，不要判断趋势方向；“看起来在下降”不算诊断
• 不要笼统地指出存在结转工作；应按根本原因类别列出数量，确保分析具有可操作性
• 不要在建议中省略明确的负责人、开始日期和可衡量目标
• 对健康状况维度评分时，必须在 Evidence 列中列出证据；缺乏依据的 Red/Yellow/Green 评分不可信