BlueGrove Labs
帮助中心StatusPath ReportsJira Cloud
联系支持
EN

使用指南

如何比较不同 Jira 团队的 Average Time in Status

要比较不同 Jira 团队的 Average Time in Status，先统一工作项总体、等价的 Review 阶段映射、历史窗口、Calendar 和团队归属规则。平均值应同时展示组内工作项数和纳入 Review 平均值的工作项数；4 个工作项得到 4.5 小时，只说明需要检查明细，不能证明它比 18 个工作项平均 6 小时的团队更快。本文用 40 个 Story 演示 Review Status Group 配置和人工验算。

跨团队 Average Time in Status 比较前的 6 项检查

负责任的比较只回答：工作在统一定义的 Review 阶段平均停留多久？ 它不能给生产力、质量或人员排名。分母和重复进入规则见 Average Time in Status 计算指南。

解释团队行之前，应统一以下六个维度：

维度 每个团队都要记录的内容
报告总体 相同的工作类型、完成标准、统计周期和排除规则。
Review 阶段映射 纳入 Review 的准确 Jira 状态及其进入、离开边界。
历史窗口 相同的 Trim History 规则和统计截止时间。
Calendar 相同的时区、工作日、工作时间、节假日和例外日期。
团队归属 分组字段、空值与转组规则，以及当前值和历史归属的处理。
证据 组内工作项数、Review 分母、逐行时长范围和抽查的 Jira History。

使用一致的 Format 便于展示和人工验算。Format 只改变显示；Calendar 决定哪些时长计入计算。

Review 分母是纳入 Review 平均值的工作项数，不是人员数或流转次数。界面中的 Work item count 是组内工作项数，并非独立的状态分母；应在对应的 Time in Status 明细中核对 Review 分母。本例每个 Story 都有一个已结束的 Review 区间，因此两者相同。

关键限制：当前 Team 值不一定代表历史团队归属

按当前值分组可能把转组前历史归入当前团队。必须定义转组规则并检查变更值和空值；无法重建历史归属时，应随结果发布限制。本文不声称 StatusPath 会自动重建历史 Team 归属。

Jira 报表提示：Control Chart 与 StatusPath 平均值默认使用不同聚合；比较前需要统一的条件见 FAQ。

受控 Jira 示例：四个团队与一个 Review 阶段

这个 40 工作项示例使用名为 Team 的自定义单选字段，Jira 类型为 Select list (single choice)，不是 Jira 原生 Team 字段。字段值是 Team Atlas、Team Borealis、Team Cygnus 和 Team Delta。本文未验证原生 Team 分组；Atlassian 的字段类型指南分别列出这两种字段。

四个团队对同一业务 Review 阶段使用两种 Jira 状态名称：

自定义 Team 值 团队使用的 Jira 状态 StatusPath Status Group
Team Atlas In Review Review
Team Borealis Waiting for Review Review
Team Cygnus In Review Review
Team Delta Waiting for Review Review

把多个 Jira 状态映射到一个看板列不会创建 StatusPath Status Group。列与分组指南说明如何在 Columns manager 中用 In Review 和 Waiting for Review 配置 Review。

每个 Story 都遵循相同的受控历史结构：

2026-07-06 08:00 UTC       创建于 To Do
1–3 小时后                  流转至 In Progress
经过受控区间后               流转至该团队的 Review 状态
经过下列 Review 时长后        流转至 Done

没有 Story 被重新打开；每个 Story 只进入一次其团队的 Review 状态，区间均已结束，且被测历史中 Team 未变更。因此本例组内工作项数等于 Review 分母；生产数据不能默认如此。

人工验算 Average Time in Status

团队 组内工作项数 纳入 Review 平均值的工作项数 Review 合计 Review 平均值
Team Atlas 18 18 108h 6h
Team Borealis 6 6 24h 4h
Team Cygnus 12 12 60h 5h
Team Delta 4 4 18h 4.5h

本例每个 Story 都进入一次 Review，所以两列数量相同；这不是生产数据的默认假设。

各工作项的 Review 小时数如下：

Team Atlas，SR-4301–SR-4318：    3, 4, 4, 5, 5, 5, 5, 6, 6, 6, 6, 6, 6, 7, 7, 8, 8, 11
Team Borealis，SR-4319–SR-4324： 2, 3, 4, 4, 5, 6
Team Cygnus，SR-4325–SR-4336：   2, 3, 4, 4, 5, 5, 5, 5, 6, 6, 7, 8
Team Delta，SR-4337–SR-4340：    3, 4, 5, 6

Team Atlas Review 平均值    = 108h ÷ 18 个工作项 = 6h
Team Borealis Review 平均值 =  24h ÷  6 个工作项 = 4h
Team Cygnus Review 平均值   =  60h ÷ 12 个工作项 = 5h
Team Delta Review 平均值    =  18h ÷  4 个工作项 = 4.5h
四团队平均值的观察范围       = 6h − 4h = 2h

检查逐行时长范围

以下中位数和观察范围由同一组受控时长人工计算，只用于补充上下文，不是显著性检验，也不一定是 Average Time in Status 报表直接显示的字段。

团队 Review 时长中位数 Review 时长观察范围
Team Atlas 6h 3–11h
Team Borealis 4h 2–6h
Team Cygnus 5h 2–8h
Team Delta 4.5h 3–6h

这些算术只能支持一个结论：在记录的计算规则下，Team Atlas 的 Review 平均值比 Team Borealis 高 2 小时。

在 StatusPath Reports 中按 Team 字段比较

  1. 选择只返回 SR-4301–SR-4340 的项目、Saved Filter 或 JQL。
  2. 选择 Average Time in Status。
  3. 使用 Table，同时保留 Work item count 和 Review 平均值。
  4. 按自定义单选 Team 字段分组。
  5. 在 Columns manager 中创建 Review Status Group，加入 In Review 与 Waiting for Review。
  6. 本完整历史示例不设置 Work item date range，也不启用 Trim History。报表范围与历史窗口指南解释两者区别；这不是通用建议。
  7. 选择自定义 All time (UTC) Calendar（UTC、24×7），并把 Format 设置为 Decimal Hours。该 Calendar 名称只属于示例，不是内置默认值。
  8. 运行报表并确认：
    • Team Atlas：18 个工作项，Review 平均值 6.00 小时
    • Team Borealis：6 个工作项，Review 平均值 4.00 小时
    • Team Cygnus：12 个工作项，Review 平均值 5.00 小时
    • Team Delta：4 个工作项，Review 平均值 4.50 小时
  9. 使用相同范围和时间设置运行 Time in Status，核对逐行时长和 Review 分母。
  10. 将已验证配置保存为 Saved Report。

Saved Report 保存配置，不冻结 Jira 数据；后续工作项、字段、权限、历史、筛选器或 Calendar 变化都可能改变结果。

Average Time in Status 表格按 Team 分组，显示 Team Atlas、Team Borealis、Team Cygnus 和 Team Delta 的 Review 平均值
Review Status Group 包含 In Review 与 Waiting for Review；组内工作项数显示在各团队的 Review 平均值旁。

如何解释样本量与 Review 分母

将样本量与平均值一起阅读

大样本不一定具有代表性，小样本也不一定无效，但小组对单个工作项更敏感。Delta 增加一个 Review 为 10 小时的 Story，平均值会从 4.5 升到 5.6 小时：(18h + 10h) ÷ 5。2 小时只是四团队平均值的观察范围，本文未做显著性检验；它是调查线索，不是生产力或流程质量证据。

确认 Review 分母

Review 分母只包含纳入该平均值的工作项；从未进入 Review 的工作项不计。本例 40 个 Story 都进入 Review，所以分母与组内工作项数相同。

核对工作流与时间设置

相同 Jira 状态名称不能证明阶段边界等价。应确认 Review 的进入、离开、等待范围和流转时间；回答不同问题的阶段应分开。

Calendar 的时区、工作日、工作时间、节假日和例外日期决定计入时长；Format 只改变显示。Jira 看板工作日与 StatusPath Calendar 控件彼此独立。

检查差值背后的历史

检查短、中、长时长工作项的 Jira History，以及相关代码评审或审批系统。状态时长衡量 Jira 流转之间的时间，不证明全程都在主动工作，也不解释等待原因；可用Jira 工作流瓶颈指南形成后续问题。

跨团队比较中的常见错误

  • 用一个平均值给团队排名： 用结果选择抽查历史，不给团队或人员打分。
  • 比较状态名而非阶段边界： 记录 Review 的进入和离开规则。
  • 把组内数当作 Review 分母： 同时展示并核对两种数量。
  • 只对齐 Format 而未统一 Calendar： 先统一 Calendar 规则。
  • 把历史时长归给当前 Team 值： 定义转组规则并披露缺失的历史归属。
  • 混合开放和完成项： 统一纳入规则和截止时间；开放区间会增长。

常见问题

平均值更低就代表 Jira 团队更快吗？

不能。它只在选定状态、总体和定义下更低；还要检查样本量、工作组合、波动、边界和历史。

所有团队必须使用同一个 Jira 项目吗？

不必。Saved Filter 或 JQL 可跨项目，但纳入规则必须可比，并记录团队身份规则。

Status Group 可以归一化不同 Jira 状态名称吗？

它可以把所选 Jira 状态放在同一个 Review Status Group 下。本例每个团队只使用一个映射状态；应保留映射并核对明细行。

可见工作项数量总是 Review 分母吗？

不是。40 个 Story 都进入 Review，所以本例相同；跳过 Review 的工作项仍在组内数中，但不进入其分母。

可以把结果直接与 Jira Control Chart 比较吗？

不能直接比较。Atlassian Control Chart 文档只适用于 company-managed spaces，其他空间应先确认可用性。所选状态决定 cycle time 范围，average、rolling average 和 standard deviation 是不同信号。看板列映射不会创建 StatusPath Status Group，Jira Working days 也独立于 StatusPath Calendar。比较前必须统一总体、边界、窗口、工作时间规则、开放/完成项处理和聚合；Jira rolling average 不是 StatusPath Status Group 的 Average Time in Status 值。

相关指南

把结果转化为可审计的问题

让总体、Review 映射、历史窗口、Calendar、组内数和 Review 分母与平均值一起展示。调整工作流或人员前先检查工作项。

在 Atlassian Marketplace 试用 BlueGrove Labs 的 StatusPath Reports - Time in Status for Jira，并复用相同的自定义 Team 字段、Review Status Group 和 Calendar。保存 StatusPath Reports 产品文档和 BlueGrove Labs 支持入口；报表不会自动解释延迟、评价个人或给团队排名。

截图预览