StatusPath Reports使用指南
如何按 Sprint 创建 Jira Time in Status 报表
要按 Sprint 创建 Jira Time in Status 报表，请选择 Time in Status，把 工作项范围设为 Sprint，先选择 Jira Board，再选择 Sprint，并明确 Calendar、Format、状态列和 Trim History 规则。解释时必须先在 Jira 中核对范围：Sprint 成员关系决定工作项，Trim History 决定这些工作项的哪一段工作流历史参与计算。
如果需要把完成情况、返工和趋势一起纳入回顾，请阅读 Jira Sprint 工作流分析指南；本页只负责配置和验收流程。
Sprint 数据源会做什么，不会做什么
Atlassian 的 Sprint Report 文档适用于 company-managed Scrum space。在这一范围内，原生报表受 Board 约束，只包含匹配 Board Saved Filter 的工作项，并标记 Sprint 开始后新增的工作项。Atlassian 的 JQL 字段参考还说明，Jira 可以按 Sprint 名称或 ID 搜索 Sprint 字段。
这些事实可用于核对 Jira 工作项范围，但不能证明选择 Sprint 后，每个工作项的历史会自动按 Sprint 日期裁剪。在 StatusPath Reports 中：
- Board + Sprint 选择 Jira 为该数据源返回的工作项；
- 工作项日期范围可根据某个 Jira 日期字段继续纳入或排除工作项；
- Trim History 限制参与计算的状态历史区间；
- Calendar 决定这些区间中哪些部分计入时长。
当前控件见报表设置与范围。设置裁剪窗口前，请阅读 Jira 报表日期范围如何裁剪状态历史。
可复现 Jira 场景：Sprint 24
本次可复现演示使用 StatusPath Demo Scrum 和 StatusPath Sprint 24 中的 8 个非生产工作项。示例使用团队已配置的 UTC 24×7 Calendar，使人工结果等于时间戳差值。生产结果必须同时记录 Calendar 的工作时间与时区。
- Sprint 开始时已有 6 个工作项；
SR-3807和SR-3808在 Sprint 进行中加入；SR-3801是 Sprint 前历史对照项，其 In Progress 区间早于 Sprint 开始时间；- 报表计算时 7 个工作项为 Done；
SR-3808当前仍处于 In Review。
Jira 原生 Sprint Report 是核对 Sprint 开始后新增工作项的验收来源。SR-3801 是 Sprint 前历史对照项，因为本演示使用它较早的 In Progress 区间测试历史裁剪。该标签只描述此场景中的计算边界，并不表示该工作项属于更早的 Sprint。StatusPath 表格用于核对所选的 8 个工作项及其状态时长计算。
配置报表
- 打开 Apps → StatusPath Reports。
- 选择 Time in Status 报表类型。
- 把 工作项范围设为 Sprint。
- 选择
StatusPath Demo ScrumBoard，再选择StatusPath Sprint 24。 - 第一次验收时不限制工作项日期范围。
- 关闭 Trim History，让第一次运行使用所选工作项的完整可用历史。
- 选择团队已配置的 UTC 24×7 Calendar 和 Decimal Hours。
- 显示工作项 Key、Summary、Created、当前状态、In Progress、In Review 和 QA。
- 等待表格刷新完成，确认正好有 8 行。
如果团队需要重复运行，应保存已经验收的配置。Saved Reports 文档说明哪些范围、历史、Calendar、Format、字段和列设置会被恢复。
人工核对完整历史结果
这个验收数据集中 8 个 In Review 值固定如下：
| 工作项 | 范围角色 | In Review |
|---|---|---|
| SR-3801 | Sprint 前历史对照项 | 4.00h |
| SR-3802 | Sprint 开始时范围 | 6.00h |
| SR-3803 | Sprint 开始时范围 | 8.00h |
| SR-3804 | Sprint 开始时范围 | 5.00h |
| SR-3805 | Sprint 开始时范围 | 7.00h |
| SR-3806 | Sprint 开始时范围 | 3.00h |
| SR-3807 | 开始后新增 | 2.00h |
| SR-3808 | 当前 In Review 区间 | 49.00h |
| 合计 | 8 个贡献工作项 | 84.00h |
In Review 合计 = 4 + 6 + 8 + 5 + 7 + 3 + 2 + 49 = 84 小时
完成占比 = 7 / 8 × 100 = 87.5%
84 小时不能证明 Review 变慢的原因，87.5% 也不是 Velocity 指标；它们只是对这一固定范围和报表端点的验收值。
在不改变工作项范围的前提下测试历史边界
创建第二次运行，保持相同 Board、Sprint、Calendar、Format、字段和状态列，把 Trim History 设为 UTC 的 2026-07-06 至 2026-07-17。
SR-3801 在 7 月 6 日之前进入 In Progress。完整历史的 In Progress 为 76.00h；裁剪后只计算所选日期内的重叠部分，显示 13.00h。两次运行都保留相同的 8 个 Sprint 工作项。
这组对照证明：Sprint 选择和历史裁剪是两个独立设置。
验收清单
| 检查项 | 预期证据 |
|---|---|
| Jira 范围 | 选择正确的 Scrum Board 和 Sprint 24 |
| 原生范围变化 | Jira Sprint Report 标出 SR-3807 和 SR-3808 为开始后新增 |
| StatusPath 工作项范围 | 完整历史和裁剪后均为 8 行 |
| 完整历史计算 | In Review 合计为 84.00h |
| 当前区间 | 固定报表端点下，SR-3808 的 In Review 为 49.00h |
| 裁剪对照 | SR-3801 的 In Progress 从 76.00h 变为 13.00h |
| 稳定设置 | 对比中 Calendar、Format、字段、状态和报表端点相同 |
常见错误
只看 Sprint 名称，不核对 Board
Sprint 与 Board 相关，名称也可能相似。先选择 Board，并在接受工作项范围前核对 Jira 原生 Sprint Report。
假设 Sprint 日期会自动裁剪历史
本流程中不会自动裁剪。先决定问题需要完整生命周期还是 Sprint 日期窗口，再明确设置 Trim History。
让工作项日期范围静默排除 Sprint 前历史对照项
Created 或 Resolved 范围可能排除有效的 Sprint 成员。第一次验收保持不限制；只有问题确实需要时才增加工作项日期规则。
使用不同 Calendar 或端点比较两次结果
当前区间会随报表端点变化，工作日历还会排除非工作时间。若只验证历史边界，必须保持两者一致。
把时长表当成工作项加入 Sprint 时间的证据
范围变化应使用 Jira 原生 Sprint 证据；Time in Status 表格负责计算它收到的工作项范围的工作流历史。
常见问题
Sprint 数据源是否只包含 Sprint 日期内完成的工作？
不是。它选择所选 Board 和 Sprint 的工作项。需要把计算限定到日期窗口时，请使用 Trim History，并记录日期边界使用的时区。
为什么选择 Sprint 前必须先选择 Board？
Board 限定可用的 Sprint 上下文。Atlassian 也明确说明，原生 Sprint Report 受 Board 和 Board Saved Filter 约束。
Carryover 历史应不应该计入？
只有独立的 Sprint 成员关系证据或团队记录能够证明工作项来自上一 Sprint 时，才能把它归类为 Carryover；仅凭工作流历史早于当前 Sprint 不能得出这个结论。确认 Carryover 后，是否计入更早历史仍取决于问题。完整历史回答“所选 Sprint 工作项在完整可用生命周期中如何流转”；裁剪窗口回答“这些历史在所选日期内贡献了什么”。必须标注选择。
可以使用 JQL 代替 Sprint 数据源吗？
Jira 支持按 Sprint 名称或 ID 查询 Sprint 字段。需要额外工作项条件时可用 JQL；Board 和 Sprint 选择是最清晰配置时可用 Sprint 数据源。没有比较返回的工作项 Key 前，不能假设两种配置完全一致。
相关指南
把 Sprint 配置变成可重复的验收测试
比较结果前，记录 Board、Sprint、工作项 Key、日期控件、Trim History 规则、Calendar、Format、可见列和报表端点。先按报表设置与范围流程完成配置，再用 Saved Reports保留已审核设置。前往 Atlassian Marketplace 试用 StatusPath Reports，复现按 Sprint 取数的表格。