使用指南

如何用 Status Count 和 Transition Count 分析 Jira 返工

要在 Jira 中调查潜在返工，可以先用 Status Count（状态进入次数） 找出多次进入同一状态的工作项，再用 Transition Count（流转次数） 查看具体发生了哪些回退，例如 In Review → In Progress 或 QA → In Progress。这些只是信号，不是自动返工分类；必须先采用团队的书面定义，再到 Jira History 中人工核验代表性工作项。

这种方法比只看当前状态更可靠。一个已经处于 Done 的 Story，之前仍可能进入过三次 In Review；它也比只看耗时更具体，因为“评审时间很长”和“多次从评审退回开发”通常是两类不同问题。

如果问题是多次停留如何合并成一个累计时长，而不是这些移动是否属于返工，请使用重复进入状态计算指南。

但要注意：重复流转只是值得调查的信号，不等于已经证明存在浪费。有些团队本来就采用多轮评审，也可能因为合理原因重新打开已完成工作项。分析前应先结合团队工作流定义“返工”。

什么情况算 Jira 返工

Jira 没有一个适用于所有团队的通用“返工”字段。团队通常需要根据自己的工作流定义一个可度量的替代指标，例如：

工作项从 In Review 返回 In Progress；
工作项从 QA 或 Testing 返回 In Progress；
已完成工作项从 Done 返回进行中状态；
工作项多次进入 Blocked 或 Waiting for Review；
因为发生回退，同一条正向流转被重复执行。

建议先写下明确规则，例如：

对本团队而言，从 In Review 或 QA 返回 In Progress 记为一次返工事件。至少发生一次上述流转的工作项属于返工工作项。

这个定义可以被人工核查，也能避免把每一次重复进入状态都当成失败。第二次进入 In Progress 确实值得注意，但只有查看进入路径，才能判断它来自 Review、QA、Done，还是来自另一条正常流程。

Status Count 和 Transition Count 的区别

Atlassian 将 Jira 工作流定义为由状态和流转组成的流程。流转是单向的，因此 In Progress → In Review 与 In Review → In Progress 是两次不同方向的移动。

Status Count 统计每个工作项在当前历史窗口中进入各状态的次数，适合回答：

哪些 Story 多次进入 In Review？
哪些 Bug 反复回到 In Progress？
哪些工作项多次被 Blocked？

Transition Count 统计工作项从某个状态移动到另一个状态的次数，适合回答：

In Review 返回 In Progress 发生了几次？
回退发生在评审还是 QA？
哪些工作项从 Done 被重新打开？

可以把 Status Count 看作筛查报表，把 Transition Count 看作诊断报表。高状态次数提示某个阶段被重复进入，具体流转次数则揭示重复的来源。

计算示例：一个 Story 出现两种回退

假设 WEB-142 的状态历史如下：

To Do → In Progress → In Review → In Progress → In Review
      → QA → In Progress → In Review → Done

Status Count 会得到：

状态	进入次数
To Do	1
In Progress	3
In Review	3
QA	1
Done	1

这张表能立即显示 In Progress 和 In Review 被重复进入，但还不能解释工作项如何返回。

关键的 Transition Count 是：

流转	次数	含义
To Do → In Progress	1	正常开始开发
In Progress → In Review	3	三次提交评审
In Review → In Progress	1	一次评审回退
In Review → QA	1	一次通过评审进入 QA
QA → In Progress	1	一次 QA 回退
In Review → Done	1	最终完成路径

按照前面的团队定义，WEB-142 有 两次返工事件：一次从评审退回，一次从 QA 退回。它虽然三次进入 In Progress，但第一次是正常开始，并不应算作返工。

Jira 原生能力能做到什么

对于单个工作项，可以打开 Activity 并选择 History。Atlassian 文档说明，History 会记录字段修改以及工作项在工作流中的移动。这适合核查少量异常工作项，但如果要分析整个 Sprint 或项目，逐条打开历史很难形成稳定的统计。

JQL 可以找出发生过特定状态变化的工作项，例如：

project = WEB
AND status CHANGED FROM "In Review" TO "In Progress"
AND sprint = 42

CHANGED 运算符支持 FROM、TO、AFTER、BEFORE 和 DURING 等条件，适合筛选已知回退路径。不过，标准 JQL 结果用于返回匹配的工作项，查询本身不会生成“每个工作项发生了几次该流转”的统计列，所以它难以直接区分一次回退和四次回退。

Jira Software 的 Control Chart 适合观察 Cycle Time、Lead Time、滚动平均值、波动和异常值。Atlassian 也说明，重新打开工作项可能增加 Cycle Time。但它解决的是流动时间问题，并不是逐工作项的精确流转次数报表。

在 StatusPath Reports 中制作返工报表

1. 选择清晰的数据范围

打开 StatusPath Reports，通过 Project、已保存 Filter、JQL、Sprint 或 Epic 选择工作项。Sprint 很适合回顾会；跨团队分析可以使用统一的 Filter 或 JQL。当前范围行为参见报表设置与范围。

不要一开始就分析整个 Jira 站点。范围越清楚，结果越容易解释和核验。

2. 区分工作项筛选时间与历史计算时间

StatusPath Reports 中有两个不同的时间概念：

Work item date range 根据 Created、Updated 或 Resolved 日期决定哪些工作项进入报表；
Trim History 限制对每个工作项的哪一段历史进行计算。

例如，一个 Story 可能在上个 Sprint 开始、本 Sprint 完成。按 Resolved date 筛选会把它纳入本 Sprint 的已完成工作，但如果 Trim History 只保留本 Sprint，较早的流转可能不会计入。团队应先决定指标是“本 Sprint 完成工作中的返工”，还是“本 Sprint 内实际发生的返工事件”。

3. 先运行 Status Count

选择 Status Count，查看 In Progress、In Review、QA、Testing、Blocked 或 Done 等可能反映重复的状态。按关键状态列从大到小排序，或使用数值筛选器找出进入次数大于 1 的工作项。

Status Count 是次数报表，不由 Duration Format 或 Calendar 决定结果；但 Trim History 会改变被统计的历史窗口，因此仍可能改变次数。

按重复进入 In Progress 次数排序的 Jira Status Count 返工报表 — Status Count 会显示多次进入 In Progress 或 In Review 的工作项。

4. 再运行 Transition Count

保持相同的数据范围和历史窗口，切换到 Transition Count，重点查看团队定义中的回退方向，例如：

In Review → In Progress
QA → In Progress
Testing → In Progress
Done → In Progress

对这些列排序或筛选，即可得到需要调查的工作项。流转列来自当前数据中实际出现的流转；如果某条路径从未发生，它可能不会显示为一列。

展示返工分析所需 Jira 工作流移动的 Transition Count 报表 — Transition Count 按方向拆分每条流转，从而区分正常前进路径和从评审返回开发的路径。

5. 核查代表性工作项

选择几条次数较高的工作项，与 Jira History 逐条对照。也可以在当前 Jira 工作项中使用 StatusPath Reports 的 Issue Activity，直接查看该工作项的 Status Count 和 Transition Count。

单个 Jira 工作项的 Issue Activity 流转次数 — SR-1002 的 Issue Activity 显示两次 In Progress 到 In Review，以及一次 In Review 返回 In Progress。

这一步能够发现工作流特有的例外，例如批量流转、迁移历史、状态改名、自动化规则、合理的重新打开，或不改变状态的循环操作。

用自己的 Jira 数据验证同一条证据路径。 StatusPath Reports 由 BlueGrove Labs 开发。可在 Atlassian Marketplace 打开 StatusPath Reports，对一个已知工作流循环先运行 Status Count，再运行 Transition Count，并在 Jira History 中核查代表性工作项。它统计记录中的进入次数和流转方向，但不会自动判定返工或解释原因。无需会议或屏幕共享。

6. 保存或导出

如果团队希望重复进行相同检查，可以保存报表配置。Saved Reports 保存的是配置，不是冻结的 Jira 数据快照。需要在回顾会中共享或继续使用表格分析时，可以将当前结果导出为 CSV 或 XLSX。

常见错误

只看重复进入次数，不看进入方向

In Progress = 3 不等于发生了三次返工。第一次可能只是正常开始。应进一步查看哪些流转进入了 In Progress。

使用了不同的历史窗口

如果 Trim History 去掉了流转序列的开头或结尾，Status Count、Transition Count 与人工检查可能出现差异。共享结果时应同时记录数据范围和历史窗口。

把所有重新打开都当作缺陷

Done → In Progress 可能来自线上缺陷、需求变化、Resolution 设置错误或正常运营流程。下结论前，应加入 Resolution、工作类型、Priority、Component 或 Label 等上下文。

混淆次数与时长

一个工作项可能只进入一次评审但停留十天，另一个可能一天内发生三次短评审。次数报表衡量重复，Time in Status 衡量自然时间或工作时间。要区分等待与流程反复，通常需要结合两类指标。

把指标变成个人考核目标

如果团队只追求降低流转次数，成员可能会避免记录合理的状态变化。这个报表更适合发现流程模式和改进机会，而不是用于指责个人。

一套可复用的分析流程

每次 Sprint 回顾或月度流程复盘可以按以下方式进行：

明确定义哪些反向流转代表可能返工；
选择稳定的数据范围，例如一个 Sprint 中已完成的工作项；
用 Status Count 筛查被重复进入的阶段；
用 Transition Count 统计已定义的回退路径；
在 Jira History 中核查高次数工作项；
阅读实际工作项后再归类原因；
只有在数据范围和历史窗口一致时，才比较不同周期。

后续可以追问：Acceptance Criteria 是否不清楚？开发未准备好就进入了评审吗？QA 是否重复发现同类问题？自动化规则是否产生了意外流转？工作流是否迫使团队进入一个并不代表真实工作的状态？

用于 Sprint 回顾时，应保留相同的回退定义，并按照 Jira Sprint 工作流分析流程同时核查 Board 范围、完成情况、等待时间和趋势。

常见问题

JQL 能统计 Jira 状态变化次数吗？

JQL 的 CHANGED 可以找出发生过指定变化的工作项，并通过来源状态、目标状态、日期或操作者缩小范围。但标准 JQL 结果不会提供逐工作项的重复次数。可以先用 JQL 选择范围，再通过报表工具或基于 API 的流程计算次数。

Status Count 很高就一定是返工吗？

不一定。它只说明工作项在计算窗口内多次进入某个状态。是否属于返工，要结合具体流转路径和业务背景判断。

Status Count 和 Transition Count 应该选哪一个？

建议结合使用。Status Count 适合快速找到重复阶段，Transition Count 适合识别并统计造成重复的具体路径。

Business Hours 会影响这两类报表吗？

不会。它们统计次数，不计算时长。工作日历主要影响 Time in Status、Average Time in Status 和 Time in Assignee 等时长报表。不过，Trim History 仍会影响次数报表。

如何计算返工率？

团队可以定义：

返工率 = 至少发生一次已定义回退流转的工作项数
         ÷ 本次分析范围内的工作项总数

这是一项团队自定义流程指标，并不是 Jira 的通用内置公式。每次报告都应写明数据范围、历史窗口和纳入统计的回退流转。

将重复流转变成可核查的清单

Status Count 与 Transition Count 将 Jira 历史拆成两个互补视角：重复进入的阶段，以及实际发生的流转方向。StatusPath Reports 可以针对 Project、Filter、JQL、Sprint 或 Epic 运行这两类报表，并对结果排序、筛选、保存或导出。建议先从一个工作流和一条明确的返工定义开始，让每一个数字都可以解释、可以核验。