StatusPath Reports使用指南
Jira 平均状态时间与总状态时间的区别
Jira 某状态的总时长是所有匹配工作项贡献时长之和；该状态的平均时长是同一合计除以贡献工作项数量。九个 Review 时长分别为 1、2、2、3、4、3、5、6、10 小时，总时长是 36 小时，平均时长是 4 小时。总时长适合衡量累计负荷，平均值适合比较每个工作项的均值。
Review 总时长 = 所有 Review 时长之和
Review 平均时长 = Review 总时长 ÷ Review 贡献工作项数
同一段历史，回答两个不同问题
总时长与平均时长来自同一批时长明细，但不能互换：
| 指标 | 计算方式 | 回答的问题 | 可能隐藏的信息 |
|---|---|---|---|
| 单工作项状态时长 | 汇总一个工作项在该状态的所有区间 | 这个工作项在 Review 停留多久？ | 整个总体的累计负荷 |
| 总体状态总时长 | 汇总所有匹配工作项的 Review 值 | 这个总体累计产生多少 Review 时长？ | 负荷是否均匀分布 |
| 状态平均时长 | 总体状态总时长除以 Review 贡献者数 | 每个贡献工作项平均有多少 Review 时长？ | 分布和异常值 |
在 StatusPath Reports 中，Time in Status 提供前两个问题所需的工作项明细行，Average Time in Status 提供汇总后的算术平均值。本文的 36 小时总体合计来自对 Review 列的明确求和，不是一个单独的报表类型。
如果不确定哪些工作项应进入分母，请阅读 Average Time in Status 的贡献者和跳过状态规则。本文让九个工作项都进入 Review，只讨论总量与平均值的解读差异。
真实 Jira 场景：一个长评审改变平均值
受控的 StatusPath Reports（SR）Jira 项目包含九个已完成工作项：四个 Story、三个 Bug 和两个 Task。所有时间戳均为 UTC；报表使用已配置的 24×7 All time (UTC) Calendar 和 Decimal Hours。项目与工作项数据用于这个可复现演示；该 Calendar 名称并不表示每个安装环境都默认提供它。
| 工作项 | 类型 | 进入 In Review | 进入 Done | 计入的 Review 时长 |
|---|---|---|---|---|
| SR-4101 | Story | 2026-07-08 12:00 | 2026-07-08 13:00 | 1h |
| SR-4102 | Bug | 2026-07-08 15:00 | 2026-07-08 17:00 | 2h |
| SR-4103 | Task | 2026-07-08 13:00 | 2026-07-08 15:00 | 2h |
| SR-4104 | Story | 2026-07-08 16:00 | 2026-07-08 19:00 | 3h |
| SR-4105 | Bug | 2026-07-08 14:00 | 2026-07-08 18:00 | 4h |
| SR-4106 | Task | 2026-07-08 16:00 | 2026-07-08 19:00 | 3h |
| SR-4107 | Story | 2026-07-08 16:00 | 2026-07-08 21:00 | 5h |
| SR-4108 | Bug | 2026-07-08 18:00 | 2026-07-09 00:00 | 6h |
| SR-4109 | Story | 2026-07-08 12:00 | 2026-07-08 22:00 | 10h |
在选定日历下，SR-4109 的 10 小时可以重复验算：
2026-07-08 22:00 - 2026-07-08 12:00 = 10h
Atlassian 说明，Jira 工作项 Activity 中的 History 会记录字段编辑、工作项在工作流中的移动等更新。解释时长报表前，应先用历史记录核对这些流转时间戳：工作项中有哪些不同类型的活动？
人工验算总时长、平均值和异常值占比
先读取九个可见的 Review 值：
Review 总时长 = 1h + 2h + 2h + 3h + 4h + 3h + 5h + 6h + 10h = 36h
贡献工作项数 = 9
Review 平均时长 = 36h ÷ 9 = 4h
两边使用同九个原始时长与同一贡献者规则，因此可以对账。格式化前应满足：
总时长 = 平均时长 × 贡献工作项数
36h = 4h × 9
明细还说明为什么不能直接说“4 小时是正常水平”。SR-4109 贡献了 36 小时中的 10 小时：
异常工作项占 Review 总时长比例 = 10h ÷ 36h = 27.78%
去掉 SR-4109 后的平均值 = 26h ÷ 8 = 3.25h
分组行还需要第二次对账：
Story = (1h + 3h + 5h + 10h) ÷ 4 = 19h ÷ 4 = 4.75h
Bug = (2h + 4h + 6h) ÷ 3 = 12h ÷ 3 = 4.00h
Task = (2h + 3h) ÷ 2 = 5h ÷ 2 = 2.50h
分组均值的简单平均 = (4.75h + 4.00h + 2.50h) ÷ 3 = 3.75h
加权总体平均值 = (3 × 4.00h + 4 × 4.75h + 2 × 2.50h) ÷ 9 = 36h ÷ 9 = 4.00h
总体平均值在数学上没有错误，但一个长时长工作项把平均值从 3.25 小时推高到 4 小时。把该均值作为流程基线前，应先检查该工作项的 Jira 历史。分组结果也说明，不能对屏幕上的分组均值直接取未加权平均。
Atlassian 的 Control Chart 文档同样强调波动和异常值。原生 Control Chart 面向 company-managed 空间，按选定状态计算 cycle time 或 lead time，并显示平均值、滚动平均和标准差。这个配置后的周期指标并不自动等于本文单个 Review 状态的合计或平均值。
在 StatusPath Reports 中复现对比
1. 固定工作项总体
两个报表使用同一个 Project、Filter、JQL、Sprint 或 Epic 来源。本文场景使用：
project = SR AND key in (SR-4101, SR-4102, SR-4103, SR-4104, SR-4105, SR-4106, SR-4107, SR-4108, SR-4109) ORDER BY key ASC
Atlassian 的 JQL 高级搜索文档说明，JQL 可用于指定精确条件，ORDER BY 用于控制结果顺序。
2. 固定计算配置
使用相同的工作项日期范围、Trim History、Calendar、时区和 Format。本次核对使用：
- 不设置工作项日期范围或 Trim History；
- 选择已配置的 24×7 All time (UTC) Calendar；
- 选择 Decimal Hours。
在两次运行之间改变任一设置都会改变输入，结果就不再是干净的对账。可参考报表设置与范围和日历与时长确认控件边界。
3. 先运行 Time in Status
保留 Work item key、Work item type、Summary 和 In Review 列。确认九个 Review 单元格分别为 1h、2h、2h、3h、4h、3h、5h、6h 和 10h，再对这一列求和得到 36h。不要把每行的 Total 列相加：它会合并一个工作项的可见状态时长，回答的是另一个问题。
4. 在相同范围运行 Average Time in Status
只切换报表类型，把 Group by 设置为 Work item type，并保留 In Review 列。三行结果应分别显示：Bug 3 个工作项、4.00h；Story 4 个、4.75h；Task 2 个、2.50h。总体平均值应按加权后的 36h ÷ 9 = 4h 重建，不能使用三个已显示均值的简单平均 3.75h；只有需要一行总体结果时才清空 Group by。当前报表类型文档说明，Time in Status 每个工作项一行，而 Average Time in Status 使用带平均状态时长列的汇总行。
5. 回到明细解释结果
平均值看起来异常时，把 In Review 列按时长从高到低排序，或导出明细行进行对账。在本文场景中，SR-4109 占 Review 总时长的 27.78%。
根据决策选择指标
| 决策 | 先看什么 | 还要核对什么 |
|---|---|---|
| 找出占用 Review 时间最多的工作项 | 按 In Review 排序的 Time in Status | 排名前列工作项的 Jira History |
| 估算固定总体的累计 Review 负荷 | 汇总 Time in Status 的 Review 列 | 范围、日历、历史窗口和缺失贡献者 |
| 比较不同分组或周期的 Review 均值 | Average Time in Status | 贡献工作项数和一致的配置 |
| 判断均值能否代表多数工作项 | Time in Status 的分布 | 异常值，以及均值以外的中位数或分位数分析 |
总时长同时受工作量和时长影响。平均值通过贡献者数量做归一化，但仍会受到极端值影响。一个团队可能因为处理了更多工作项而总时长更大，但平均时长更低。
常见错误
把平均值当成累计产能负荷
九个贡献工作项的 4h 平均值代表 36h Review 时长，而不是 4h 总负荷。
累加每行 Total，而不是一个状态列
计算 Review 总时长时，只应累加 Review 单元格。每个工作项的 Total 可能包含 To Do、In Progress、Review、Done 或其他可见状态时长。
自动用所有选中工作项做分母
从未进入 Review 的工作项可能不会贡献 Review 平均值。应在平均值计算指南中核对分母规则，不要假设总体数量始终适用。
对已显示的分组平均值再求平均
如果各组贡献者数量不同，应使用原始合计与数量计算加权结果。本例中，4.75、4.00、2.50 的简单平均是 3.75，正确总体平均值则是 (3 × 4.00 + 4 × 4.75 + 2 × 2.50) ÷ 9 = 4.00 小时。
比较配置不同的两次运行
Calendar、时区、工作项日期范围、Trim History、数据范围和当前状态结束边界都会在聚合前改变时长明细。
把异常值直接当成原因
10h 只说明应从哪里开始调查；它不能证明原因是排队、返工、依赖、人员可用性或合理例外。
常见问题
状态总时长总是等于平均时长乘以贡献工作项数吗？
当两者使用同一批未舍入时长和同一贡献者规则时，是的。显示格式的舍入可能让屏幕上的乘法与原始合计略有差异。
Time in Status 会自动显示某状态的总体合计吗？
Time in Status 显示每个工作项的状态时长和每个工作项的 Total。要得到 Review 的总体合计，应在表格或导出文件中汇总 Review 列。Average Time in Status 显示的是汇总均值，不是这个总体合计。
判断瓶颈应该使用哪个指标？
两个层次都要看。较高总时长说明大量时间在哪里累计；较高平均值说明每个贡献工作项平均在哪里停留更久。命名瓶颈前应检查最长的明细行。
可以把这个平均值直接与 Jira Control Chart 对比吗？
不能在没有统一定义时直接比较。Control Chart 的 cycle time 或 lead time 可以组合多个选定状态，并有自己的总体、时间范围和滚动平均行为。应先统一这些输入，再与单状态 Average Time in Status 比较。
如果一个工作项从未进入 Review 呢？
此时选中总体与 Review 贡献工作项数可能不同。总时长仍汇总实际 Review 贡献，平均值则必须采用产品的 Review 贡献者规则。可在分母指南中查看完整示例。
相关指南
用明细解释平均值
用状态总时长衡量累计负荷，用 Average Time in Status 比较每个贡献工作项的均值。保持总体、状态、历史窗口和日历完全一致；只要平均值需要解释，就回到 Time in Status 明细行。
在 Atlassian Marketplace 试用 StatusPath Reports，使用自己的 Jira 工作项和权限复现明细与平均值对比。