使用指南

Jira Sprint 工作流分析：状态时间、返工与趋势

Jira Sprint 工作流分析应把范围和完成情况与基于历史的证据结合起来。先使用 Jira Sprint Report 确认受 Board 约束的 Sprint 工作项和范围变化，再用 Time in Status、Status Count、Transition Count 和趋势找出等待与重复流转。整个过程必须保持 Board、Sprint、历史窗口、Calendar 和返工定义一致。

Sprint 范围和工作流历史属于不同层次

Atlassian 的 Sprint Report 文档适用于 company-managed Scrum space。在这一范围内，报表受 Board 约束，只包含匹配 Board Saved Filter 的工作项，并会标记 Sprint 开始后新增的工作项。team-managed space 的报表入口和可用报表集合不同，因此执行本流程前应先核对实际 space 中提供的报表。这个区别只限定 Jira 原生 Sprint Report 的说明，不把下文基于历史的工作流分析限定为某一种 Jira space。

回顾问题	使用的证据
哪些工作完成了，哪些在开始后加入？	Jira Sprint Report
单个工作项在哪里等待？	Time in Status
哪个阶段平均时长最长？	Average Time in Status 和贡献工作项数
哪些工作项重复进入 Review 或 QA？	Status Count
循环的具体方向是什么？	Transition Count
延迟是否跨 Sprint 或周期重复？	Status Trend 或跨报表趋势

如果需要在所有数据源和输出格式之间做选择，请阅读Jira 工作流报表完整指南；本页聚焦 Sprint 回顾顺序。

真实 Jira 场景：22 个工作项、Review 回退和 Carryover

假设 StatusPath Sprint 8 的评审范围包含 22 个工作项：

报表计算时 18 个已完成；
4 个尚未完成；
Sprint 结束后，其中 1 个未完成工作项被移入下一个 Sprint，并在本次回顾中按团队规则计为 Carryover；
5 个工作项至少一次从 In Review 返回 In Progress；
22 个工作项都进入过 In Review，累计 140 小时。

初步计算为：

完成占比          = 18 / 22 × 100 = 81.8%
Review 循环占比   =  5 / 22 × 100 = 22.7%
平均 Review 时间  = 140h / 22 = 每个贡献工作项 6.36h

这些数字回答不同问题：完成占比描述范围结果；Review 循环占比是团队定义的返工信号；平均 Review 时间描述时长，不表示回退次数或原因。

StatusPath 中包含 22 个工作项的 Jira Sprint Time in Status 表格 — Sprint 数据源保持评审范围可见，行级状态时长显示工作项在哪里等待。

可重复执行的 Sprint 分析顺序

1. 确认 Board 和 Sprint 工作项范围

记录 Board、Sprint、起止日期、Board Filter、开始后新增或移除的工作项，以及 Subtask 规则。Atlassian 说明 Sprint Report 不包含 Subtask 估算，也不显示 Subtask 的 Sprint 专属完成明细。

2. 写出回顾问题

把结果问题和过程问题分开：

结果：哪些完成、Carryover 或发生范围变化？
等待：哪些状态停留最久？
返工：哪些预先定义的向后流转发生了？
负责人：是否存在交接或未分配区间？
趋势：信号是重复出现还是孤立异常？

3. 明确选择时间和历史时间

Sprint 数据源选择工作项；Trim History 控制每个已选工作项中参与计算的状态和负责人历史。如果工作项在 Sprint 前已经开始，完整历史与 Sprint 窗口历史回答的是不同问题。可按照 Sprint 数据源配置与验收指南设置并比较两个边界，同时保持工作项范围不变。

4. 先查看明细表

对 Sprint 数据源运行 Time in Status，保留 Review、QA、Blocked 和必要的工作项字段。按目标状态从长到短排序，同时检查普遍延迟和异常值。如果参与比较的工作流使用不同详细状态名称，应先用状态分组设计与验算指南定义共同的 Review 或 Validation 阶段。

5. 使用次数报表分析返工

先用 Status Count 筛选重复阶段，再用 Transition Count 验证书面定义。本场景的定义是 In Review → In Progress。具体核查方式见Jira 返工指南。

6. 比较趋势时保留相同定义

跨周期比较时使用相同状态、Calendar、时区和历史规则。使用不同工作流映射计算出的下降平均值不能证明同口径改善。下图不是累计曲线：每个点表示该日时间桶内贡献的汇总时长，标签单位为十进制天。

StatusPath Status Trend 图表用于 Jira Sprint 工作流回顾 — 按日趋势以十进制天显示各状态的汇总时长；重点比较 In Review 与 QA 可定位评审阶段压力，零值表示在所选 Calendar 和历史设置下，该时间桶没有计入任何时长。

当前趋势控件见图表视图文档，Sprint 选择和 Trim History 见报表设置与范围。

7. 核查代表性工作项

在 Jira History 中检查时长最高的工作项、一个重复流转工作项、Carryover 工作项和一个普通已完成工作项。不能仅凭表格数值判断原因。

Jira Control Chart 在分析中的位置

Atlassian 的 Control Chart 文档说明，Cycle time 由所选工作流列决定，重新打开的工作会增加时长。该图适合查看 Cycle time 变异、滚动平均值和异常值。

Time in Status 和流转报表回答更具体的问题：每个工作项究竟在哪个状态累积时间、哪些方向的移动重复发生。两层证据可以配合使用，但不能声称状态时长表与配置后的 Control Chart 是同一个指标。

常见错误

把 Sprint 字段当作完整范围定义

Sprint 报表与 Board 和 Board Filter 绑定。应记录 Board 并核对实际工作项范围。

混合完整生命周期和 Sprint 窗口历史

完整历史回答“这些 Sprint 工作项整体如何流转”，裁剪历史回答“这个窗口内发生了什么”。必须标注选择。

把每次重复进入 Review 都称为缺陷

Review 回退可能来自未完成工作、需求变化、自动化或有效流程。必须检查流转方向和工作项历史。

比较平均值时忽略贡献工作项数

两个工作项的平均值不能与二十个工作项的平均值直接等量解释。

使用等待时间给个人排名

状态和负责人时长包含队列、依赖、休假和非工作时间，只能作为过程信号。

常见问题

Jira Sprint Report 足够用于回顾吗？

它是确认 Board 专属 Sprint 范围和完成情况的主要原生来源。如果回顾还需要状态等待、交接或具体工作流循环，再加入基于历史的报表。

应如何处理 Carryover？

先写明团队对 Carryover 的定义，把它作为范围结果明确保留，并决定工作流计算使用完整历史还是仅 Sprint 窗口。本场景记录的是未完成工作项被移入下一个 Sprint；Carryover 不能根据状态时长推断。两个历史窗口不能静默混合。

实用的 Sprint 返工指标是什么？

先定义一条或多条向后流转，再用至少发生一次定义流转的工作项数除以评审范围，并记录流转列表和历史窗口。

工作日历会影响返工次数吗？

不会。日历影响时长报表；Status Count 和 Transition Count 是事件次数，但 Trim History 仍会改变纳入的事件。

两份 Sprint 工作流报表都正确但结果不同，可能吗？

可能。它们可能使用了不同 Board Filter、Sprint 范围快照、历史窗口、Calendar、状态或贡献规则。

把 Sprint 回顾变成可验证的过程问题

有效的 Sprint 分析先记录范围，再用一致规则检查完成情况、状态等待、重复流转、负责人和趋势。StatusPath Reports 可以对 Sprint 数据源运行六种基于历史的报表，并将配置保存为 Saved Report，供下一次回顾重复使用。

前往 Atlassian Marketplace 试用 StatusPath Reports，用自己的 Scrum Board 和 Jira 权限复现这套工作流检查。