开放的当前状态区间如何改变平均状态停留时间

在一组受控配置下，即使没有工作项发生新的状态流转，一个开放的当前 In Review 区间仍会改变分组 Average Time in Status。两个已完成贡献保持 2 小时和 4 小时不变，一个开放贡献从 3 小时增长到 5 小时。相同 3 个贡献者的分子因此从 9 小时变为 11 小时，平均值从 3.00 小时变为 3.67 小时。精确增量是 2h ÷ 3 = 0.666666...h；Decimal Hours 两个显示值之差是 0.67 小时。

本指南只解释分组平均值

这是一篇桥接指南，只回答一个问题：一个开放的当前区间如何改变分组平均值？它不重复单个工作项区间模型、通用分母规则，也不重讲平均值与总值的区别。相关基础分别见为什么 Jira 当前状态的停留时间会持续增长、Jira 状态平均时长如何计算和Jira 平均状态时间与总状态时间的区别。

Jira 工作项 Activity 区域中的 History 会记录字段编辑和工作流移动。使用 Atlassian 的工作项 Activity 文档核对每个工作项何时进入和离开 In Review。Jira History 提供这些事件；StatusPath 再应用报表边界、Calendar、分组和平均规则。

已记录的 Jira 观察：一个当前 In Review 区间

受控总体包含 3 个工作项。两个工作项已经完成 In Review 区间，第三个仍在 In Review。下表记录了同一份报表在 2026 年 7 月 14 日 12:00 和 14:00 UTC 的两次观察。这些是已记录的运行时刻，不是读者之后可以输入的报表结束时间。

两次观察都使用以下完全相同的配置：

两次已记录观察之间，不修改 Jira 历史、范围、分组、Calendar、Format、日期筛选或 Trim History；只有有效报表结束边界向后移动 2 小时。

没有新流转仍会增长的五个条件

本受控示例同时满足以下五个条件：

1. SR-5203 仍在 In Review，因此当前区间没有已记录的退出。
2. 第二次运行采用更晚的有效结束边界。
3. 没有固定的 Trim History end 在较晚边界之前封顶当前区间。
4. 所选 All time 模式会计入两个以 UTC 记录的边界之间全部 2 个自然小时。
5. 两次运行使用相同的范围、历史窗口、分组、状态选择和权限，Project 分组中的 3 个 In Review 贡献者也保持不变。

只要其中任一条件不同，就不能把全部变化归因于开放区间。

计算 12:00 的平均值

在 12:00 UTC，受控 History 表明 3 个工作项都对 In Review 产生了计算记录，因此该状态的贡献者数量为 3：

In Review 分子 = 2.00h + 4.00h + 3.00h = 9.00h
In Review 贡献者 = 3

In Review 平均时长 = 9.00h ÷ 3 = 3.00h

可见的 Work item count 是 Project 分组的总体数量，不能单独证明某个状态的分母。将鼠标悬停在 In Review 平均值单元格上，或用键盘把焦点移到该单元格，可以查看合计时长、参与者数量和公式。在本受控数据中，该公式确认 9.00 小时来自 3 个 In Review 贡献者。需要逐行核对公式时，再使用 Time in Status 明细。

计算 14:00 的平均值

在 14:00 UTC，两个已完成区间保持不变。SR-5203 仍处于 In Review，因此它的贡献从 3.00 小时增长到 5.00 小时：

In Review 分子 = 2.00h + 4.00h + 5.00h = 11.00h
In Review 贡献者 = 3

In Review 原始平均时长 = 11.00h ÷ 3
                       = 3.666666...h
Decimal Hours 显示值   = 3.67h

分子精确增加 2 小时，分母仍为 3，因此平均值的精确增量是 2h ÷ 3 = 0.666666...h。Decimal Hours 把两个端点显示为 3.00 小时和 3.67 小时，显示值相减得到 0.67 小时。0.67 小时是显示差值，不是未舍入的精确增量。StatusPath 先汇总原始 duration，再用原始合计除以贡献者数量，只在最终显示时舍入；不要先舍入每条贡献，也不要把 3.67 用作后续计算输入。

分母也可能发生变化

In Review 贡献者数量只在本受控示例中保持为 3。以下情况都可能改变它：

• JQL、Work item date range、权限或工作项可见性增加或移除已选工作项；
• 另一个已选工作项第一次对 In Review 产生贡献；
• Trim History 删除某个工作项的全部 In Review 计算记录，或纳入另一个工作项的记录；
• Jira History 被修正、删除、恢复或发生其他影响状态证据的变化；或者
• 分组字段值或分组配置把工作项移入或移出被比较的行。

如果第四个已选工作项第一次对 In Review 产生贡献，分子和分母都会变化；平均值可能升高，也可能降低。在把平均值变化解释成当前区间增长前，应先检查 In Review 公式证据。

在 StatusPath Reports 中复现

1. 选择你自己的有界总体，其中包含已完成的 In Review 贡献，以及至少一个当前仍在 In Review 的工作项。
2. 打开 Average Time in Status，选择该范围，并核对每个工作项的 Jira History。
3. 两次运行之间保持 Work item date range 和 Trim History 不变。固定的 Trim History end 会在该边界封顶开放区间，因此之后运行也不会让它继续越过该上限。
4. 两次运行选择同一个 Calendar。如需 24×7 自然时间对比，使用 All time、用 UTC 记录运行时间，并选择 Decimal Hours。
5. 按需要比较的字段分组，并保持 In Review 可见。
6. 在第一次未来运行时，记录运行时刻、可见的 Work item count、In Review 平均值，以及 In Review 单元格中的参与者数量和公式。
7. 在之后的一次运行中，确认当前工作项仍未发生新的状态流转，重新运行完全相同的报表并记录同样的证据。
8. 在 Time in Status 中核对已完成贡献和当前贡献。你的数值取决于实际 Jira History 和两次运行之间的时长，不需要等于上面已记录的 12:00 和 14:00 观察值。

可参考报表类型了解 Average Time in Status 行为，并参考报表设置与范围了解 JQL、日期范围和 Trim History 控件。

区分 Jira 原生指标

Atlassian 的 Control Chart 文档说明，该图表针对选定状态计算周期时间或前置时间，并为 company-managed space 显示平均值、滚动平均、标准差和异常值。它与 StatusPath 按 Project 分组的 In Review Average Time in Status 不是同一个指标，也不使用同一个公式；仅仅把 Calendar 设为一致，并不会让数值等价。Control Chart 不能验证这里的 9h ÷ 3 或 11h ÷ 3。比较前必须对齐总体、所选状态、时间范围、当前/开放工作项处理、工作日定义和聚合方式。

常见错误

只解释单个当前时长

当前区间解释了 SR-5203 为什么增长；分组平均值还需要另外两个 In Review 贡献值和该状态的贡献者数量。

认为没有流转就不会变化

只有当区间保持开放、报表边界向后移动、Calendar 计入这段时间，而且受控总体和贡献者集合保持不变时，才不需要新的 Jira 流转也会出现这类增长。

在两次运行之间修改报表配置

不同的 JQL、权限、日期筛选、Trim History、Calendar、Format 或分组会破坏受控比较。

把 0.67 小时称为精确增量

精确增量是 2h ÷ 3 = 0.666666...h。报表显示 3.00 小时和 3.67 小时，二者可见差值才是 0.67 小时。

假设分母一定不变

分母只在本受控示例中保持 3。范围、权限、Trim History、分组，或某个已选工作项第一次对 In Review 产生贡献，都可能改变分母。

直接与 Control Chart 比较

Control Chart 配置的周期时间或前置时间指标，不使用与本 In Review 分组平均时长相同的公式。

常见问题

为什么没有工作项流转，平均值仍会变化？

SR-5203 一直处于 In Review，有效边界向后移动，24×7 UTC Calendar 计入这 2 小时，而且受控贡献者集合仍为 3。

为什么 SR-5203 在两个时刻都算贡献者？

它在第一次已记录观察前已经进入 In Review，并且在两次运行中都产生了 In Review 计算时长。

3.67 小时是逐项舍入造成的吗？

不是。原始时长合计为 11.00 小时，11 ÷ 3 = 3.666666...，最终在 Decimal Hours 中显示为 3.67。

新增 In Review 贡献者会使平均值下降吗？

可能。新工作项会同时改变分母和分子。如果它的 In Review 贡献低于之前的平均值，即使 In Review 总时长增加，新平均值仍可能下降。

Saved Report 会冻结这个平均值吗？

不会。Saved Report 保存可复用配置，不会冻结 Jira 数据或结果行。开放区间和贡献者集合在以后运行时都可能变化。

相关指南

• Jira 状态平均时长如何计算
• 为什么 Jira 当前状态的停留时间会持续增长
• Jira Time in Status 日期范围如何裁剪历史
• Jira 平均状态时间与总状态时间的区别

同时核对变化的分子与分母

只有把开放的当前区间、已完成贡献、有效报表边界、Calendar 计入的时间和状态贡献者数量，在同一份不变配置下核对一致，才能解释持续变化的 In Review 平均值。

在 Atlassian Marketplace 试用 StatusPath Reports，对照 Jira 分组状态平均值与其背后的工作项时长。