Back to Details

agile-metrics

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sprint Metrics

Sprint 指标

Use this skill to extract objective metrics from sprint artifacts and generate a quantitative summary.
使用此技能从Sprint工件中提取客观指标并生成定量总结。

Language

语言

Write the artifact in the user's language. If the user communicates in Portuguese, write in Portuguese with correct grammar and accents. If in English, write in English. When in doubt, ask the user which language to use. Templates are in English — translate headers and content to match.
以用户使用的语言撰写工件内容。如果用户使用葡萄牙语交流，则用葡萄牙语撰写，确保语法和重音正确；如果使用英语，则用英语撰写。如有疑问，请询问用户使用哪种语言。模板为英语版本，请将标题和内容翻译成对应语言。

Objective

目标

  • Consolidate sprint data into concrete numbers
  • Feed retro and sprint review with facts, not impressions
  • Identify patterns between sprints (improvement or degradation)
  • Support capacity and planning decisions
  • 将Sprint数据整合为具体数值
  • 为回顾会议和Sprint评审提供事实依据，而非主观印象
  • 识别Sprint间的模式（改进或退化）
  • 支持产能规划与决策

When to use

使用场景

  • At the end of the sprint, before review or retro
  • When the team needs data to discuss performance
  • To compare sprints and identify trends
  • When there is doubt if declared capacity is calibrated
  • Sprint结束后，评审或回顾会议之前
  • 团队需要数据来讨论绩效时
  • 对比Sprint情况并识别趋势时
  • 对已声明的产能是否合理存在疑问时

Collected metrics

收集的指标

Delivery

交付

  • Total planned stories/items
  • Total delivered vs not delivered
  • Completion rate (%)
  • Items added during the sprint (scope creep)
  • Items removed or postponed
  • 计划的故事/任务总数
  • 已交付与未交付的总数
  • 完成率（%）
  • Sprint期间新增的任务（范围蔓延）
  • 移除或推迟的任务

Quality

质量

  • Bugs found during the sprint
  • Bugs found after delivery
  • Test coverage (if measurable)
  • Lint, typecheck, or test failures at closing
  • Sprint期间发现的缺陷
  • 交付后发现的缺陷
  • 测试覆盖率（若可衡量）
  • 收尾时的代码检查、类型检查或测试失败情况

Flow

流程

  • Registered blockers (quantity and average duration)
  • Average time between story start and completion
  • Stories that returned from "done" to "in progress"
  • 记录的障碍（数量和平均持续时间）
  • 故事从开始到完成的平均时间
  • 从“已完成”退回至“进行中”的故事

Process

过程

  • Status checkpoints held vs expected
  • Status closure reports generated
  • Issues opened vs closed
  • 实际召开的状态检查点 vs 计划召开的数量
  • 生成的状态收尾报告数量
  • 已创建 vs 已关闭的问题

Process

流程步骤

1. Collect data

1. 收集数据

Consult sprint artifacts:
  • Sprint planning (committed items)
  • Issues (opened, closed, blocked)
  • Status checkpoints (blockers, progress)
  • Status closure reports (executed verifications)
  • Commits and PRs (volume of changes)
查阅Sprint工件：
  • Sprint规划（承诺的任务）
  • 问题（已创建、已关闭、已阻塞）
  • 状态检查点（障碍、进度）
  • 状态收尾报告（已执行的验证）
  • 提交记录和PRs（变更量）

2. Calculate metrics

2. 计算指标

Fill the template with real numbers. Don't round to look better — precision matters more than appearance.
用真实数值填写模板。不要为了好看而四舍五入——准确性比外观更重要。

3. Analyze trends

3. 分析趋势

If there is data from previous sprints, compare:
  • Is the completion rate improving?
  • Are blockers decreasing?
  • Is scope creep under control?
如果有之前Sprint的数据，进行对比：
  • 完成率是否有所提升？
  • 障碍是否减少？
  • 范围蔓延是否得到控制？

4. Generate summary

4. 生成总结

The summary must be short enough to read in 2 minutes.
总结需简洁，确保能在2分钟内读完。

Template

模板

markdown
undefined
markdown
undefined

Sprint Metrics: <Sprint>

Sprint 指标: <冲刺名称>

Context

背景

  • Project/team:
  • Period:
  • Declared capacity:
  • 项目/团队:
  • 周期:
  • 声明的产能:

Delivery

交付

  • Planned: X items
  • Delivered: Y items (Z%)
  • Added during sprint: W items
  • Removed/postponed: V items
  • 计划: X 项任务
  • 已交付: Y 项任务 (Z%)
  • Sprint期间新增: W 项任务
  • 移除/推迟: V 项任务

Quality

质量

  • Bugs during sprint: N
  • Bugs post-delivery: N
  • Lint/typecheck/tests: passed / failed (detail)
  • Sprint期间发现的缺陷: N
  • 交付后发现的缺陷: N
  • 代码检查/类型检查/测试: 通过 / 失败（详情）

Flow

流程

  • Blockers: N (average duration: X days)
  • Average time per story: X days
  • Reopenings: N stories
  • 障碍: N 个（平均持续时间: X 天）
  • 单故事平均耗时: X 天
  • 重新打开的故事: N 个

Process

过程

  • Status checkpoints: X of Y expected
  • Closure reports: X of Y deliveries
  • Issues closed: X of Y
  • 状态检查点: 计划 Y 个，实际召开 X 个
  • 收尾报告: 交付 Y 项，生成 X 份
  • 已关闭问题: 总数 Y 个，已关闭 X 个

Trend vs previous sprint

与上一Sprint的趋势对比

  • Completion rate: up/down/stable (X% vs Y%)
  • Blockers: more/less/same
  • Scope creep: more/less/same
  • 完成率: 上升/下降/稳定（X% vs Y%）
  • 障碍: 增多/减少/持平
  • 范围蔓延: 增多/减少/持平

Highlights for retro

回顾会议要点

  • Positive point:
  • Attention point:
  • Action suggestion:
undefined
  • 积极点:
  • 注意点:
  • 行动建议:
undefined

Rules

规则

  • Metrics are reflection tools, not judgment tools. The goal is to improve the process, not evaluate people.
  • Never manipulate numbers to look better. If the sprint was bad, the numbers should reflect that — and the retro should discuss why.
  • Compare sprints carefully. Different contexts (vacations, external blockers, team changes) invalidate direct comparisons.
  • Metrics without discussion are useless. Always present within a retro or review, never as an autonomous report.
  • 指标是反思工具，而非评判工具。目标是改进流程，而非评估个人。
  • 绝不要篡改数据来粉饰结果。如果Sprint表现不佳，数据应如实反映——回顾会议需讨论原因。
  • 谨慎对比Sprint情况。不同的背景（假期、外部障碍、团队变动）会使直接对比失去意义。
  • 没有讨论的指标毫无用处。务必在回顾或评审会议中呈现，切勿作为独立报告发布。

Relationship with the flow

与流程的关系

mermaid
flowchart LR
    A["/agile-sprint"] --> B[execution]
    B --> C["/agile-status"]
    C --> D["/agile-metrics"]
    D --> E["/agile-review"]
    E --> F["/agile-retro"]
Sprint metrics feeds 
/agile-review
and 
/agile-retro
. Use 
/agile-status
for tracking during the sprint.
mermaid
flowchart LR
    A["/agile-sprint"] --> B[execution]
    B --> C["/agile-status"]
    C --> D["/agile-metrics"]
    D --> E["/agile-review"]
    E --> F["/agile-retro"]
Sprint指标为
/agile-review
和
/agile-retro
提供数据支持。Sprint期间的进度跟踪请使用
/agile-status
。