评估需求积压严重程度，需要把需求池条目拆成规模、老化、流入流出三个口径分别计算，再组合判断。单看条目总数无法说明积压是否已经影响交付；当积压工作量相对团队产能的消化周期持续拉长、超期条目占比上升、新增长期多于关闭时，积压才构成对交付的实际挤压。下面给出一套可复算的指标、口径、计算步骤与算例。
要点总览（TL;DR）
- 评估需求积压严重程度，要把条目总数拆成规模、老化、流入流出三类口径分别计算，再组合判断；单看总数无法说明是否已影响交付。
- 规模看积压条目数、积压工作量与消化周期（积压工作量÷团队单位周期可消化工作量），消化周期持续拉长说明积压正在挤压交付。
- 老化看等待时长中位数与P75、超期条目占比；流入流出看新增速率、关闭速率与净增长率，净增长连续为正且关闭速率未同步上升是恶化信号。
- 判定采用组合规则：三项信号满足两项及以上判为严重，阈值取自团队历史基线或约定目标，不套用外部通用达标线。
- 指标反映积压状态，不能直接归因于团队效率；估算覆盖率不足时消化周期只作参考，建议固定周期复算看趋势而非单次快照。
评估目标：判断积压是否已经影响交付
“积压严重”是一个结论，评估的任务是把它拆成三个可以用数据回答的判断问题，让结论有依据、可复核。
- 规模是否超出产能：需求池里待处理的工作量，按团队当前消化速度需要多久才能清空。这个问题回答“排得下还是排不下”。
- 条目是否老化：等待中的需求已经等了多久，有多少超过了约定的处理时限。这个问题回答“积压是否在变质”，因为等待过久的需求往往价值衰减、上下文丢失、返工增加。
- 流入流出是否失衡：单位时间内新增与关闭的数量关系。这个问题回答“积压是在恶化还是在收敛”，决定清理动作是否见效。
条目总数不足以判断严重程度，原因在于它把三种不同性质的信息压成了一个数字。同样50条积压，若每条平均1人天、每周关闭15条，两周即可清空；若每条平均5人天、每周关闭3条，则需要两个多月。总数相同，对交付的影响完全不同。总数也无法反映结构：积压里有多少是三个月前的老条目，近期是净增还是净减，这些信息决定应该采取排期、清理还是控制入口的动作。
评估结果有三个直接用途：排期决策上，用消化周期判断新需求进入迭代的节奏是否需要收紧；清理动作上，用老化分布定位优先处理哪些条目；向上沟通上，用三类指标的组合说明积压现状与趋势，替代“需求太多做不完”这类无法核对的表述。
指标与范围：积压规模、老化、流入流出三类指标
三类指标各自回答一个问题，需要同时统计。统计对象统一为需求池中尚未进入迭代的条目，Sprint Backlog 内的条目属于已承诺工作，不计入积压；需求的价值评分用于排序，不参与严重程度计算。
| 类别 | 指标 | 含义 | 统计对象 | 时间窗 |
|---|---|---|---|---|
| 规模 | 积压条目数 | 统计截止时点需求池中未进入迭代的条目总数 | 需求池条目 | 时点值 |
| 规模 | 积压工作量 | 上述条目工作量估算之和，单位为人天 | 已估算的需求池条目 | 时点值 |
| 规模 | 消化周期 | 积压工作量 ÷ 团队单位周期可消化工作量 | 需求池与团队产能 | 以周或月为单位 |
| 老化 | 等待时长 | 条目进入需求池至统计截止点的天数，看中位数与P75 | 需求池条目 | 时点值 |
| 老化 | 超期条目占比 | 等待时长超过约定时限的条目数 ÷ 积压条目数 | 需求池条目 | 时点值 |
| 流入流出 | 新增速率 | 时间窗内新进入需求池的条目数 ÷ 周期数 | 需求池条目 | 周或月 |
| 流入流出 | 关闭速率 | 时间窗内离开需求池的条目数（进入迭代、关闭、合并）÷ 周期数 | 需求池条目 | 周或月 |
| 流入流出 | 净增长率 | （新增数 − 关闭数）÷ 期初积压条目数 | 需求池条目 | 周或月 |
统计范围需要在计算前书面约定三件事：需求池的状态定义，即哪些状态算“在池中”，通常包括待评审、待排期、已排期未进迭代；时间窗长度与统计截止点，建议按周或按月固定，截止点统一为周期最后一天；条目类型边界，明确缺陷、技术任务、运营请求是否纳入，纳入则全程一致，不中途改变。
数据口径：分母、时间窗与缺失值处理
同一组数据在不同口径下会算出不同结论，因此每个指标都要写清分子、分母、单位与截止点，并对常见数据问题预设处理规则。
- 消化周期：分子为积压工作量（人天），分母为团队过去若干周期的平均可消化工作量（人天/周）。分母建议取最近4至8周的实际完成量均值，避免用理论产能。
- 超期条目占比：分子为等待时长超过约定时限的条目数，分母为统计截止时点的积压条目总数。约定时限由团队设定，例如待评审超过14天、待排期超过30天。
- 净增长率：分子为时间窗内新增数减关闭数，分母为期初积压条目数。用期初数作分母，使不同规模的池子可以横向比较。
- 工作量未估算的条目：单独列出数量并计算估算覆盖率（已估算条目数 ÷ 积压条目数），不默认按零计入工作量。覆盖率低于约定水平（如80%）时，消化周期只作参考，需在结论中注明。
- 状态回退：条目从迭代退回需求池时，按当前状态计入积压，等待时长从退回日重新起算，并单独记录回退次数，避免把回退造成的积压误读为新增流入。
- 重复条目：合并前单独标记，不直接删除，统计时保留在总数中并注明待合并数量，防止清理动作虚增关闭速率。
- 跨池移动：条目在需求池与迭代之间移动时，以统计截止点的状态为准，同一时间窗内进出多次只计一次净变化。
- 分母为零：期初积压为零时，净增长率写“不适用”，不写零或无穷；团队某周期无完成记录时，消化周期的分母取更长窗口的均值，仍无数据则标注“数据不足”。
计算与评估步骤：从取数到判定严重程度
按以下五步执行，每步产出可核对的数据，最后用组合规则给出严重程度判断。
- 确定范围与时间窗。导出统计截止点的需求池条目清单，字段包括状态、进入池日期、工作量估算；同时导出最近8周的完成记录用于计算产能。完成标志是清单条目数与系统筛选结果一致。
- 计算规模指标。统计积压条目数、积压工作量与估算覆盖率；用积压工作量除以周均可消化工作量，得到消化周期（周）。
- 计算老化指标。对每条积压条目计算等待天数，取中位数与P75；按约定时限统计超期条目数，计算超期占比。
- 计算流入流出指标。按周统计新增数与关闭数，计算平均新增速率、平均关闭速率与各周期净增长率，观察净增长是否连续为正。
- 组合判定严重程度。将三项判断并列，按下表规则给出等级。
| 判断项 | 关注信号 | 判定依据 |
|---|---|---|
| 规模 | 消化周期超过约定目标且连续两个统计周期上升 | 团队约定的可接受消化周期，如不超过6周 |
| 老化 | 超期占比高于团队历史基线，或等待时长P75明显上升 | 历史基线或约定的超期比例上限 |
| 流入流出 | 净增长率连续三个周期为正，且关闭速率未同步上升 | 团队约定的净增长容忍区间 |
判定规则建议采用组合而非单一阈值：三项信号中满足两项及以上判为严重，满足一项判为需要关注，均不满足判为可控。阈值来源必须是团队历史基线或明确约定的目标，例如取过去半年消化周期的中位数作为参照，不套用外部通用达标线。团队业务节奏不同，阈值也应不同，季度性需求高峰前可临时放宽规模阈值，同时收紧老化阈值。
在数据记录环节，需求池条目、状态与工作量估算需要有稳定的承载位置。ONES Project 支持建立需求池、规划迭代，并自定义需求状态与多种属性，任务工时统计可用于积累工作量与产能数据；报表支持自定义数据范围和维度，便于按周复算上述指标。若需要把来自各方的反馈先收集再转入需求池，ONES 敏捷研发管理方案中可用工单收集整理反馈并转化为需求，整理出产品 Backlog。老化分布与流入流出速率是否已有预置报表，需以实际配置确认，通常可通过筛选与自定义维度组合得出。
算例：一个需求池的积压评估过程
以下数字均为演示用假设数据，不代表任何真实团队情况。
假设数据：统计截止时点需求池共80条，其中64条有工作量估算，合计320人天，估算覆盖率80%。团队最近8周平均每周完成40人天。等待时长中位数45天，P75为70天；约定待排期时限30天，超期条目24条。最近4周新增分别为12、15、14、13条，关闭分别为8、9、7、10条。期初积压72条。
- 规模：积压条目数80条，积压工作量320人天，消化周期 = 320 ÷ 40 = 8周。若团队约定可接受消化周期为6周，规模信号成立。
- 老化：超期占比 = 24 ÷ 80 = 30%。等待时长P75为70天，超过30天时限两倍以上。若历史基线为15%，老化信号成立。
- 流入流出：周均新增 = (12+15+14+13) ÷ 4 = 13.5条；周均关闭 = (8+9+7+10) ÷ 4 = 8.5条；净增长 = 13.5 − 8.5 = 5条/周。4周净增长合计20条，净增长率 = 20 ÷ 72 ≈ 27.8%，且每周均为正。流入流出信号成立。
综合判定：三项信号全部成立，判为严重。结论可表述为：当前积压工作量按现有产能需8周消化，超过6周目标；三成条目等待超过30天；周均新增13.5条、关闭8.5条，积压以每周约5条的速度净增。建议同时收紧需求入口、对超期条目安排集中评审，并在下个周期复算关闭速率是否上升。
解读与限制：指标能说明什么、不能说明什么
三类指标描述的是积压的状态与趋势，不构成对团队效率的判断。消化周期变长可能来自需求集中涌入、估算口径变化或人员调整，需要结合具体背景解释，不能直接归因为团队产出下降。
- 估算误差会传导到消化周期。工作量估算偏低的条目越多，消化周期越被低估。估算覆盖率低于约定水平时，应把消化周期标注为参考值，并优先补齐关键条目的估算。
- 阈值需要随团队与业务节奏调整。历史基线是起点，不是固定标准。业务扩张期净增长为正可能是正常现象，关键看关闭速率是否同步提高。
- 积压高不等于交付差。需求池中保留一定数量的候选需求是正常的产品管理状态。判断是否影响交付，应结合迭代按时完成情况、交付周期、缺陷趋势等结果指标交叉验证。
- 单次快照容易误判。季度末、大版本发布前后数据波动明显，建议固定周期复算，观察连续三个周期以上的趋势，再决定是否调整排期或启动清理。
- 指标不覆盖质量与价值。积压条目中高价值需求与低价值需求被同等计数，评估严重程度时可结合价值评分分层查看，但价值评分本身不进入本文的计算口径。
把上述口径固定下来并按周复算，积压评估就从一次性的争论变成可追溯的趋势记录，排期、清理与沟通都能引用同一组数字。
常见问题
需求池条目总数不多，但团队仍感觉交付吃紧，这种情况怎么判断积压是否严重？
条目总数少不代表积压轻，关键看工作量与消化周期。可以统计积压条目的工作量估算之和，除以团队最近4至8周的周均完成工作量，得到消化周期。若消化周期明显超过团队约定的可接受周期，即使条目数不多，也说明积压正在挤压交付。同时查看等待时长分布，若少量条目已等待很久，老化信号同样成立。
工作量估算覆盖率很低时，消化周期还能用吗？
可以用，但要标注为参考值。建议先单独统计未估算条目数，计算估算覆盖率（已估算条目数÷积压条目数），不把未估算条目默认按零计入工作量。覆盖率低于团队约定水平（如80%）时，消化周期会偏低，结论中应注明这一限制，并优先补齐关键条目的估算后再复算。
团队没有历史基线，第一次评估时阈值怎么定？
可以先用最近半年到一年的实际数据算出各指标的中位数作为起点，例如消化周期中位数、超期占比中位数，再结合业务节奏约定一个可接受目标。阈值不是固定标准，业务扩张期净增长为正可能是正常现象，重点看关闭速率是否同步提高。首次评估的结论建议以趋势观察为主，连续复算三个周期以上再调整阈值。
条目从迭代退回需求池，算新增流入还是积压？
按当前状态计入积压，等待时长从退回日重新起算，并单独记录回退次数。这样处理可以避免把回退造成的积压误读为新增流入，也能在解读时区分“外部新需求涌入”和“已承诺工作退回”两种不同原因。跨池移动以统计截止点的状态为准，同一时间窗内进出多次只计一次净变化。
积压指标显示严重，是否说明团队效率有问题？
不能直接这样归因。三类指标描述的是积压的状态与趋势，消化周期变长可能来自需求集中涌入、估算口径变化或人员调整。判断是否影响交付，应结合迭代按时完成情况、交付周期、缺陷趋势等结果指标交叉验证。积压高也不必然等于交付差，需求池保留一定数量的候选需求是正常状态，关键是看趋势是否持续恶化。
