统计需求积压老化程度，核心是把“池子里有多少条”拆成三个可复算的量：积压规模（未关闭需求的条数与工作量）、老化分布（每条需求在池中停留多久、各时长档占比）、流入流出平衡（同一时间窗内新增与关闭/交付的速率差）。停留天数以需求首次进入需求池的日期为起点，以关闭或进入迭代的日期为终点，按自然日计算；再统计中位数、P75、P90和超阈值占比，结合流入流出比判断积压是在恶化还是自然消化。以下给出指标定义、数据口径、计算步骤与一个月的算例。
要点总览（TL;DR）
- 老化程度以需求在池中的停留时长为基本度量：起点取首次进入需求池的日期，终点取关闭或进入迭代的日期，按自然日计算。
- 积压规模要同时看条数与工作量；老化分布用中位数、P75、P90和超阈值占比描述，分位数比平均值更能反映长尾。
- 流入流出比用同一时间窗内新增条数除以关闭或进入迭代条数，比值持续大于1说明积压在恶化。
- 分母为零或有效条目少于20条时，只报告绝对数、明细和中位数，不强行给出P90与占比。
- 停留时长反映排队情况，不直接等于交付质量或团队绩效，阈值需结合团队节奏设定，并看多期趋势。
评估目标：判断积压是否已影响交付
“需求池条目持续增加”本身只是一个规模信号，它可能来自业务活跃、准入宽松，也可能来自交付能力不足。老化统计的任务是把规模信号拆成三个可以分别回答的问题，再决定采取哪种管理动作。
- 积压规模问题：池中未关闭需求有多少条、合计多少工作量？规模是否超出团队一个或几个迭代的消化能力？对应动作通常是扩容评估或分批清理。
- 老化程度问题：需求在池中等待了多久？长尾有多长，多少条目已超过团队约定的等待阈值？对应动作通常是排期调整、明确搁置或关闭。
- 流入流出失衡问题：新增速率是否持续高于关闭/交付速率？对应动作通常是收紧准入条件、调整需求评审节奏。
这三类问题需要分开看：条目多但停留时间短，说明池子周转正常，只是流量大；条目不多但P90很长，说明少数需求被长期搁置，会拖累对外承诺的可信度。统计结果服务于排期、清理、扩容和准入调整四类决策，不用于评价个人产出。
本方法聚焦需求池层面的等待与流量，不涉及Sprint Backlog的迭代内管理，也不涉及需求价值评分与优先级排序方法——后者决定“先做哪个”，老化统计回答“等太久的是哪些、积压是否在恶化”。
指标与范围：统计哪些需求、算哪些数
纳入统计的集合是统计截止时点仍未关闭、且尚未进入迭代的需求条目，包括待评审、已评审未排期、已排期未进入迭代等状态。已关闭（含已交付、已拒绝、已合并）的条目和已进入迭代的条目不计入积压规模，但它们的关闭或进入迭代日期会作为停留天数的终点参与历史计算。
时间窗建议按自然月统计，同时保留滚动90天视图：自然月便于与月度评审节奏对齐，滚动90天能平滑单月波动、覆盖跨月等待的长尾需求。两个视图使用同一套指标定义，避免口径漂移。
| 指标 | 公式 | 单位 | 分母/说明 |
|---|---|---|---|
| 积压条数 | 统计时点未关闭且未进入迭代的条目数 | 条 | 无分母，直接计数 |
| 积压工作量 | 上述条目预估工作量之和 | 人天或故事点 | 仅统计已估算条目，并注明估算覆盖率 |
| 停留天数 | 终点日期 − 起点日期 | 自然日 | 逐条计算，作为分位数输入 |
| 停留天数中位数 | 停留天数序列的第50百分位 | 天 | 分母为纳入计算的条目数 |
| P75 / P90 | 停留天数序列的第75、90百分位 | 天 | 同上；P90反映长尾 |
| 超阈值占比 | 停留天数 > 阈值 的条目数 ÷ 有效条目数 | % | 分母为停留天数有效的条目数 |
| 流入流出比 | 时间窗内新增条数 ÷ 同窗关闭或进入迭代条数 | 比值 | 分母为关闭+进入迭代条数 |
积压规模同时看条数与工作量，是为了避免大量小需求掩盖少数大需求造成的交付压力；工作量指标需注明估算覆盖率，未估算条目单独计数，不与已估算条目混算。
数据口径：起止时间、状态与缺失值怎么处理
可复算的前提是每条需求都有明确的起点和终点。起点取需求首次进入需求池的日期，终点取关闭日期或进入迭代日期，两者取先发生者。按自然日计算，不扣除周末与节假日，保证不同团队、不同月份之间可比；如需按工作日口径，应在报告中标明并保持各期一致。
状态回退与重新打开
需求被退回、重新打开或从迭代中撤出时，保留首次进入池的日期作为起点，不重置计时；另设“重新打开次数”字段单独记录。这样停留天数反映的是需求从提出到最终落位的真实等待，而不是最后一次状态变更后的时间。若需求撤出迭代后重新回到池中，其终点改为最终关闭或再次进入迭代的日期。
缺失值与重复条目
- 创建日期为空：以状态流转记录中最早一次进入池状态的时间补齐；两者都缺失时标记为“口径缺失”，计入积压条数但不计入分位数与超阈值占比，并单独报告缺失条数。
- 停留天数为负或为零：核对日期字段是否被手工改写，无法核实的条目列入异常清单，不参与计算。
- 重复条目：按需求唯一编号去重；同一业务诉求拆成多条记录的，在统计说明中注明拆分规则，避免规模被放大。
分母为零与样本过小
某时间窗内关闭或进入迭代条数为零时，流入流出比不计算，只报告新增条数与期末积压条数，并注明“分母为零”。有效条目数少于20条时，分位数与占比的波动较大，建议只报告绝对数、逐条明细和中位数，不给出P90与超阈值占比，或明确标注“样本过小，仅供参考”。
计算步骤：从原始条目到老化分布
整个计算可以在一张明细表中完成，步骤固定，便于每月重复和交叉复核。
- 导出条目明细：字段至少包括需求编号、需求类型、来源、当前状态、首次进入池日期、关闭日期、进入迭代日期、预估工作量、重新打开次数。
- 清洗：按编号去重，剔除测试数据，按上一节规则补齐或标记缺失日期，生成异常清单。
- 计算单条停留天数：对每条需求取终点日期（关闭与进入迭代中较早者，均无则取统计截止日）减起点日期，得到自然日天数。仍在池中的条目以统计截止日计算“已等待天数”。
- 汇总分位数与分档占比：对有效停留天数排序，取中位数、P75、P90；按团队约定阈值分档（例如0–30天、31–60天、61–90天、90天以上），计算各档条数与占比。
- 计算流入流出比：在同一时间窗内统计新增条数与关闭+进入迭代条数，两者相除；同时给出滚动90天的比值观察趋势。
- 拆分对比：按需求类型（如缺陷类、优化类、新功能类）或来源（如客户、内部、运营）分别计算上述指标，识别老化集中在哪一类。
分位数建议用排序后按位置取值的方式计算，并在报告中写明所用方法（如线性插值或取最近秩），保证不同月份、不同人复算结果一致。
算例：一个月的积压老化统计
以下为演示数据，用于说明公式与解读方式，不代表任何真实团队水平。假设某产品团队统计3月需求池，期末未关闭且未进入迭代的需求共40条，其中36条停留天数有效，4条因创建日期缺失被标记；团队约定等待阈值为60天。
停留天数与分位数
将36条有效需求的停留天数升序排列，第18与第19位分别为27天和31天，中位数取两者平均为29天；第27位为58天，即P75为58天；第33位为96天，即P90为96天。分档结果为：0–30天14条（38.9%），31–60天11条（30.6%），61–90天6条（16.7%），90天以上5条（13.9%）。超过60天的条目共11条，超阈值占比为11÷36≈30.6%。
| 指标 | 结果 | 计算说明 |
|---|---|---|
| 积压条数 | 40条 | 含4条口径缺失条目 |
| 有效条目数 | 36条 | 分位数与占比的分母 |
| 停留天数中位数 | 29天 | 第18、19位平均 |
| P75 | 58天 | 第27位 |
| P90 | 96天 | 第33位 |
| 超阈值占比（>60天） | 30.6% | 11 ÷ 36 |
| 流入流出比 | 1.6 | 48 ÷ 30 |
流入流出比
3月新增需求48条，同期关闭或进入迭代30条，流入流出比为1.6，大于1，说明当月积压净增18条。结合滚动90天比值若仍在1.3以上，可以判断积压在持续恶化，而非单月偶发波动。
结果对应的动作
中位数29天说明一半需求在一个月内能被处理，周转尚可；P90达到96天、超阈值占比超过三成，说明长尾明显。可执行的动作包括：对90天以上的5条逐条评审，明确排期、搁置或关闭；对61–90天的6条确认是否仍有效；针对流入流出比1.6，收紧新需求准入或增加一轮集中评审。若拆分后发现长尾集中在某一来源，可优先与该来源约定提交规范。
解读与限制：指标说明什么、不能说明什么
停留天数反映的是需求在池中的等待时间，它说明流程中的排队情况，不直接等于交付质量，也不能作为团队绩效结论。一个等待时间长的需求，可能因为依赖外部条件而合理搁置；一个等待时间短的团队，也可能只是大量关闭了需求。解读时应结合关闭原因分布一起看。
- 可比性：需求类型混杂时，缺陷类与大型新功能类的合理等待时间差异很大，混算会拉偏分位数，建议按类型拆分后再比较。
- 样本量：条目数少的月份，P90由个别条目决定，波动大，应看滚动多期趋势而非单期数值。
- 阈值设定：60天或90天只是示例，阈值应结合团队迭代长度、需求评审周期和对外承诺节奏设定，不存在通用达标线。
- 趋势优先：单期快照只能说明当下状态，连续三个月的中位数与超阈值占比走向，才能判断管理动作是否生效。
- 指标边界：老化统计不评价需求价值高低，也不替代交付质量、缺陷率等指标；它回答的是“等了多久、积压是否在恶化”。
把统计落到需求池日常管理
统计要能持续复算，前提是需求池的字段和状态流转被稳定记录。每条需求至少需要首次进入池日期、当前状态、关闭日期、进入迭代日期、预估工作量、来源与类型这些字段，状态变更留有历史记录，停留天数才能按统一口径重算。状态命名也应保持稳定，避免同一含义的状态在不同月份使用不同名称，导致跨期对比失真。
节奏上，建议每月出一次统计报告，与需求评审会合并进行：先看积压条数与工作量是否超出下个迭代的消化能力，再看超阈值条目清单，最后看流入流出比趋势。会议产出应落到具体条目和具体动作——哪些关闭、哪些排期、哪些搁置、准入条件是否调整，并在下期统计中回看这些条目的状态变化。
ONES 在需求池记录与状态跟踪上可以承载这套流程：ONES Project 支持建立需求池、规划迭代，可编写需求并自定义需求状态与多种属性，将需求和相关任务规划至迭代、分配负责人（F3）；任务筛选器支持全局与项目内多重条件筛选，便于按状态、类型、来源拉取待统计条目（F5）；多种报表可按自定义数据范围和维度呈现项目表现（F4）。在业产研协同场景中，统一的业务需求池、产品需求池与工单系统把业务反馈与产品开发衔接起来，需求来源与状态信息可追溯（F1、F2），为按来源拆分老化指标提供记录基础。停留时长分位数、老化分档与流入流出比这类指标，可按本文口径基于条目明细计算，具体报表字段与统计方式以实际项目配置为准。
常见问题
需求在池中等待期间被退回或重新打开，停留天数要不要重新计时？
建议保留首次进入需求池的日期作为起点，不因状态回退或重新打开而重置计时，另设“重新打开次数”字段单独记录。这样停留天数反映的是需求从提出到最终落位的真实等待。若需求曾进入迭代后又撤出，终点改为最终关闭或再次进入迭代的日期，起点仍不变。
团队需求条目很少，每月只有十几条，还能算P90和超阈值占比吗？
有效条目数少于20条时，P90往往由一两个条目决定，波动很大。此时建议只报告积压条数、工作量、中位数和逐条明细，并标注“样本过小，仅供参考”；也可以把统计窗口拉长到滚动90天，用更多条目支撑分位数。超阈值占比同样应谨慎给出，或改为直接列出超阈值条目清单。
流入流出比的分母为零怎么处理？
某时间窗内关闭或进入迭代条数为零时，流入流出比不计算，只报告新增条数、期末积压条数和积压工作量，并注明“分母为零”。连续多期分母为零本身就是需要关注的信号，说明池中需求没有出口，应优先检查排期与关闭机制。
统计结果能不能直接用来评价团队交付绩效？
不建议。停留天数说明需求在池中的排队情况，等待时间长可能来自依赖外部条件、评审周期长或准入过宽，等待时间短也可能来自大量关闭需求。评价交付应结合关闭原因分布、交付质量与缺陷率等指标。老化统计的用途是发现长尾条目、判断积压趋势，并据此决定清理、排期、扩容或收紧准入。
用ONES记录需求池时，哪些字段需要提前规范，才能每月复算老化指标？
至少需要首次进入池日期、当前状态、关闭日期、进入迭代日期、预估工作量、来源与类型，并保留状态变更历史。ONES Project 支持建立需求池、规划迭代，可编写需求并自定义需求状态与多种属性（F3）；任务筛选器支持全局与项目内多重条件筛选，便于按状态、类型、来源拉取待统计条目（F5）；多种报表可按自定义数据范围和维度呈现项目表现（F4）。状态命名应保持稳定，避免同一含义在不同月份使用不同名称。停留时长分位数、老化分档与流入流出比可按本文口径基于条目明细计算，具体报表字段以实际项目配置为准。
