我们砍掉了故事点，用优先级排序

一、我们错了：故事点把复杂度变成了一个可以讨价还价的数字

2024年第三季度，我们在 PingCode 内部对 200 人以上的产品线做了一次深度复盘。结果让我们很难堪：在 Sprint 规划会议中，团队平均花费 47% 的时间在故事点估算上，而真正讨论“这个需求到底解决什么问题”的时间，只有 18%。

更扎心的是，我们把 Sprint 交付数据拉出来一看，那些花了大量时间“精确估算”到 3 点、5 点、8 点的需求，最终的实际交付质量与那些只做了优先级排序、没做故事点估算的需求，在客户满意度指标上没有显著差异。

这意味着什么？我们在用一个看似科学的度量工具，消耗团队将近一半的规划精力，但它对最终交付价值几乎没有贡献。

那一刻我意识到，故事点不是工具的问题，是思维范式的问题。它让我们误以为“能够被量化”就等于“能够被管理”，而实际上我们管理的只是一个自我安慰的数字。

2024 年 Q4，我们在 PingCode 最大的三条产品线，Project（项目管理）、Testhub（测试管理）、Insight（效能度量），同时启动了一个实验：完全砍掉故事点估算，用优先级排序替代 Sprint 规划。

这篇文章，就是那个实验的真实复盘。不美化，不布道，只讲我们实际遇到的问题、踩过的坑、拿到的数据，以及哪些情况下你不应该跟风这么做。

二、核心结论：我们砍掉的不是故事点，是“伪确定性”

先把最核心的判断放在前面，后面再慢慢展开论证。

故事点本身没有原罪。真正的问题是：中大型组织很容易把故事点从一个相对估算工具，异化成衡量团队绩效的硬指标。

这个过程是渐进的、不易察觉的。一开始团队引入故事点是为了更好地理解工作的相对规模。然后管理层开始问：“每个 Sprint 能交付多少故事点？”团队开始汇报：“我们这个 Sprint 交付了 42 点，比上个 Sprint 的 38 点提升了 10%。”再然后，故事点开始和团队资源分配挂钩：“你们团队每个 Sprint 只能交付 30 点，隔壁团队能交付 50 点，是不是你们效率有问题？”

到了这一步，故事点已经彻底异化了。它从团队内部的沟通工具，变成了管理层衡量效率的抓手。而一旦它变成一个衡量指标，它就一定会被博弈，这是组织的铁律。

我们在 PingCode 内部观察到至少三种博弈行为：

• 故事点通胀：同样的需求，三个月前估 3 点，现在估 5 点。不是因为需求变大了，而是因为团队学会了“给自己的交付结果留余地”。
• 估算政治：产品经理在规划会议上刻意把需求拆得更细，让每个故事点看起来都很小，以便在“总点数”上显得交付量很大。
• 故事点防御：工程师在估点时倾向于往高估，因为“估低了会被追问进度，估高了提前交付还能被表扬”。

这些行为没有任何人刻意为之，它们是在“故事点=绩效信号”的环境下理性个体的自然反应。就像古德哈特定律说的：当一个度量成为目标，它就不再是一个好的度量。

所以我们砍掉故事点，不是因为它是错的，而是因为在 100 人以上的组织里，保持故事点不异化的管理成本，远高于它带来的收益。

优先级排序替代故事点的本质，是把团队从“估算能做完多少”的思维框架里拉出来，塞进一个完全不同的框架：“在有限的时间里，我们应该优先交付什么”。

前者关注的是产出（output），后者关注的是成果（outcome）。这是两个完全不同的管理逻辑。

三、真实场景还原：一个 120 人产品线的 Sprint 规划是怎么跑偏的

1. 背景：PingCode Project 产品线的典型 Sprint 规划

PingCode Project 是我们核心的项目管理产品线，团队 120 人左右，拆成 7 个特性团队（Feature Team），每个团队 8-15 人不等。Sprint 长度统一为两周。

在砍掉故事点之前，我们的 Sprint 规划流程是这样的：

1. 需求池准备：产品负责人从 Backlog 中筛选出当前优先级最高的需求，通常 20-30 个 Epic/Feature 级别的大需求。
2. 需求讲解：产品负责人在规划会议上逐条讲解这些需求，回答团队的技术疑问。
3. 故事点估算：团队用 Planning Poker 对每个需求进行故事点估算。这是一个通常耗时 1.5-2 小时的环节。
4. 能力匹配：根据团队历史 Velocity（比如每个 Sprint 稳定在 35-40 点），从高优先级需求中尽可能多地放入当前 Sprint。
5. 任务拆解：对纳入 Sprint 的需求进行具体开发任务拆分。
6. 承诺 Sprint 目标：团队对 Sprint Backlog 达成共识，形成 Sprint Goal。

这个流程听起来很标准，完全符合 Scrum Guide 的推荐。但实际的体验呢？我们录了一组真实的会议数据：

2. 关键观察：估算环节的认知负载远高于价值讨论

2024 年 8 月的一个 Sprint 规划会议，时长 3 小时 15 分钟。我们做了逐分钟的编码分析：

这个数据让我非常不安。一个 3 小时的 Sprint 规划会，近一半时间用来争论一个本质上无法精确预测的数字，而真正决定交付价值的需求理解和 Sprint 目标制定，加起来只有 30% 多。

更讽刺的是，那次 Sprint 结束后，我们发现放在 Sprint 里“估了 3 点”的一个需求和“估了 8 点”的另一个需求，实际开发时间只相差了 1.5 天。

这就回到了一个根本问题：故事点估算的精度到底有多高？如果它的误差范围本身就很大，那花一半规划时间去追求这个精度的意义是什么？

四、拆解常见误区：为什么“砍掉故事点”不等于“放弃规划”

1. 误区一：故事点是唯一能衡量团队能力的方式

这是最常见的反驳观点。“你不估算故事点，怎么知道团队能完成多少？怎么控制 Scope？”

这个观点的隐含假设是：故事点是一个相对稳定的、可预测的度量单位。但至少在我们 PingCode 内部的观察里，这个假设不成立。

我们抽样分析了 2024 年 Q1-Q3 三条产品线的故事点数据，计算了每个团队 Story Point Velocity 的波动率（标准差/均值）。结果如下：

平均波动率超过 30%。这意味着如果团队平均交付 40 点，实际交付范围大致在 28-52 点之间摇摆。用这样一个高波动的指标来“控制 Scope”，实际上是一种虚假的控制感。

我们不是不需要估计，而是发现故事点这种估计方式的回报太低。高投入（规划时间）+ 低精度（高波动）+ 高副作用（博弈行为），这三个特征叠加，让故事点在中大型组织中变成了一个负和的游戏。

2. 误区二：砍掉故事点就是放弃量化管理

这是第二个常见误解。很多人把“故事点”和“量化”画等号，以为不用故事点了就回退到“拍脑袋”的时代。

实际上，我们用优先级排序替代故事点后，引入了一套更聚焦结果的量化体系。区别在于，旧体系度量的是“投入”（完成了多少点），新体系度量的是“产出成果”：

• 需求流动效率：一个需求从“待规划”到“已交付”的平均周期时间（Cycle Time）
• 关键需求覆盖率：每个 Sprint 中，被标记为“高优先级”的需求占 Sprint Backlog 的比例，以及它们的实际完成率
• 延迟成本密度：被推迟的高优先级需求，每推迟一个 Sprint 造成的业务影响估算（这个我们后面会详细展开）
• Sprint 目标达成率：Sprint 结束时，团队是否达成了 Sprint Planning 时定义的 Sprint Goal（二进制指标：达成/未达成）

这套指标体系的问题域从“这个 Sprint 做了多少点”变成了“这个 Sprint 把最重要的需求交付了没有”。后者才是对业务有意义的度量。

3. 误区三：优先级排序会变成产品经理的一言堂

这个顾虑很合理。砍掉故事点后，规划流程中缺少了一个“团队对话空间”，原来的估算环节虽然低效，但它至少是一个强迫团队一起看需求的机制。如果直接把这个环节拿掉，优先级排序会不会变成产品负责人单方面的排期行为？

我们在实验初期确实遇到了这个倾向。某些团队直接把“优先级排序”理解成“产品经理排个序，研发拿来就做”，这导致了两个问题：

• 技术风险被忽视：产品经理从业务价值角度把某个需求排在 P0，但团队实际评估后发现技术依赖未就绪，根本做不了。
• 团队 Owner 意识退化：认为“既然不用我们估点，那我们也不用多想，产品给啥做啥就行”。

如果这就是优先级排序的样子，那它比故事点估算更糟糕。

所以我们做了关键的架构调整，不是“取消估算环节”，而是用“决策对齐环节”替代它。这个后面会详细讲。

五、我们的方案：用“决策对齐”替代“故事点估算”

1. 核心框架：从“估算多少”切换到“决定什么最重要”

砍掉故事点后，我们重新设计了 Sprint 规划会议的结构。新流程包含四个核心环节：

1. 价值宣讲（30 分钟）：产品负责人讲解当前 Backlog 中最高优先级需求，重点不是讲功能描述，而是讲清楚“这个需求解决谁的什么问题、不做的代价有多大”。
2. 决策对齐（45 分钟）：团队对优先级排序进行集体校验，用我们设计的“决策卡片”机制让每个人都有发言权。这是我们用来替代故事点估算的核心环节。
3. 任务拆解（30 分钟）：对纳入 Sprint 的需求进行技术拆解，确定技术方案和任务归属。
4. Sprint 目标锁定（15 分钟）：用一句话定义本 Sprint 的可验证成果，明确成功标准。

整个会议控制在 2 小时以内，比原来的 3-3.5 小时缩短了约 35%。

关键环节是第二项，决策对齐。它的设计理念是：不要估算“这个需求需要多少工作量”，而是团队共同确认“这个 Sprint 我们的能力边界在哪里，以及在这个边界内我们应该优先做哪些事”。

2. 核心工具：决策卡片机制

这是我们实验中最关键的发明（我们 2024 年 10 月还专门为这个机制申请了一个 PingCode 的产品内测功能）。具体做法如下：

第一步：产品负责人准备决策卡片

每个高优先级需求制作一张决策卡片，卡片包含：

• 需求名和一句话描述（20 字以内说清楚是什么功能）
• 价值陈述（为谁解决什么问题，用第一人称用户语气写）
• 不做的影响（分三个等级：致命/严重/可承受）
• 技术依赖标记（是否有前序需求依赖，标记来自技术负责人的初步评估）
• 建议的优先级等级：P0（本周必须）、P1（本周应该）、P2（可推迟）、P3（暂不规划）

第二步：团队集体校验

在 Sprint 规划会上，所有决策卡片投影到共享屏幕上。每个团队成员有 5 张“优先票”（虚拟或实体均可，我们在 PingCode 里开发了一个电子投票功能）。每个人独立投票，可以集中投给某个需求，也可以分散投给多个需求。

投票有约束规则：每个人都必须先阅读所有 P0 需求的技术依赖标记，确认“我负责的模块是否有阻塞风险”，然后才能投票。这确保技术视角被强制纳入决策。

第三步：计算优先级共识分

投票结束后，每个需求得到两个维度的分数：

• 业务优先级分：产品负责人独立设定的 P0/P1/P2 等级，转换为 3/2/1 分
• 团队共识分：该需求获得的优先票数占总票数的比例

两个分数加权计算，得出最终的“Sprint 优先级指数”。权重可以调整，我们默认是业务优先级分占 60%、团队共识分占 40%。

第四步：画出能力边界线

不用故事点，那怎么画 Sprint 的容量线？我们用了一个粗略但足够实用的替代方案：参考过去 6 个 Sprint 的需求交付数量。

如果团队过去 6 个 Sprint 平均稳定交付 8-10 个需求（不按点数，单纯按“完成的需求个数”算），那本次 Sprint 就按 8-10 个需求的容量来规划。把“Sprint 优先级指数”最高的 8-10 个需求纳入 Sprint Backlog，剩下的全部进入“备选池”。

这个方法比故事点粗糙吗？是的。但它足够好用吗？过去 3 个 Sprint 的数据显示，以需求个数为单位的容量偏差率是 12% 左右，而故事点的容量偏差率是 30%。更粗糙的指标反而预测更准。为什么？因为这避免了故事点通胀和估算博弈带来的系统性偏差。

3. PingCode 产品线实际应用数据

我们在 PingCode Project 产品线实施了 3 个 Sprint（6 周）后，收集了以下对比数据：

需要诚实地说，3 个 Sprint 的数据量不足以得出统计意义上的结论。但趋势已经让三个产品线的负责人一致决定继续跑下去。到 2025 年 Q1，我们已经在 PingCode 内部 7 条产品线全面推广了这个模式。

六、风险与应对：优先级排序不是银弹

1. 风险一：优先级定义不清导致混乱

砍掉故事点最容易暴露的一个问题是：原来团队对“优先级”没有统一的定义。

在没有故事点之前，产品经理说“这个需求优先级高”，团队默认理解是“哦，排前面做就行”。但什么是 P0？什么是 P1？每个人心里标准都不一样。有人觉得“客户在群里催了”就是 P0，有人觉得“不做会影响续费”才是 P0。

这个问题在用故事点的时候被掩盖了，因为故事点承担了“物理排序”的功能，你故事点估出来了，按优先级从高到低放进 Sprint，放到装不下为止。优先级不够清晰没关系，故事点会自动帮你“截断”。

但砍掉故事点后，优先级定义不清晰的问题立刻暴露。有一次两个产品经理在 Sprint 规划会上争论一个需求到底该不该进 Sprint，争论的焦点不是技术评估，而是两个人对“P0 优先级”的认知完全不同。一个认为是“客户威胁要退款”，一个认为是“竞品已经上线了类似功能”。

我们的应对是：在团队层面建立明确的、可执行的优先级定义标准。我们制定了 PingCode 内部统一的优先级分级标准：

这个标准被贴在每个团队的 Sprint 会议室墙上。在优先级争论发生时，Sprint Master 的职责就是引导双方回到这个标准上，不讨论“我觉得有多重要”，只讨论“它满足哪一条判断条件”。

2. 风险二：技术债务和基础设施工作被系统性边缘化

这是一个非常真实的问题。优先级排序天然有利于“能讲出业务价值”的需求，面向客户的功能优化、解决客户痛点的修复、能带来增长的新特性。但技术债务清理、架构升级、自动化工具建设这些工作，很难在业务价值维度上和客户需求竞争优先级。

用故事点的时候这个问题也存在，但故事点至少给技术债务留了一条路，你把它写成一个需求，估个 5 点放进 Sprint 里。可一旦进入纯优先级排序，技术债务几乎每次都输。

我们观察到实验开始后的前两个 Sprint，技术债务修复类需求的入选率从原来的约 15% 骤降到约 3%。研发负责人开始坐不住了。

我们的应对分两步：

第一步：给技术需求设计“延迟成本换算”

技术负责人需要学会用业务语言描述技术债务的成本。不是讲“这个模块耦合度高需要重构”，而是讲“如果这个模块不重构，预计下个季度每新增一个功能，开发成本会增加 30%，响应时间会从现在的 2 天延长到 5 天”。

我们内部有一个简单的换算表：

• 性能型技术债务：当前页面加载时间 × 每月用户访问量 × 每增加1秒加载时间导致的跳出率提升 → 折算为“每月流失用户数”
• 可维护型技术债务：当前新功能开发平均耗时 × 预计下季度新增功能数量 × 因架构问题导致的额外耗时比例 → 折算为“下季度额外消耗人天”
• 安全型技术债务：依赖库版本过期的 CVE 数量 × 影响面评估 → 折算为“潜在的安全事件风险等级”

第二步：建立“技术健康预算”制度

这是更根本的解决方案。我们规定，每个 Sprint 的容量的 20% 必须预留给技术债务和技术基础设施建设。这 20% 不受业务优先级排序影响，由技术负责人直接决定分配。

这意味着每个 Sprint 实际用于业务需求的容量只有 80%，即大约 6-8 个业务需求（按我们团队的平均容量 8-10 个需求计算）。

这个决定在管理层层面是有阻力的。产品副总裁觉得这等于“承认 20% 的研发资源不直接对业务产出负责”。但研发副总裁的反驳很直接：“如果我们不预留这 20%，半年后 100% 的资源都会被技术债务拖慢 30%。”最终数据支持了研发侧的判断。

3. 风险三：多团队并行时缺乏跨团队容量协调机制

在 PingCode 120 人的 Project 产品线里，7 个特性团队并不是完全独立的。一个大的 Epic 往往需要 2-3 个团队协作完成。用故事点的时候，跨团队的容量协调相对直观，A 团队说这个需求我们估 8 点，B 团队说我们这边估 5 点，加起来 13 点，看看各自团队还剩多少点容量就知道能不能接。

砍掉故事点后，跨团队协调出现了一个真空。需求个数不能直接相加，同样是一个“需求”，A 团队负责后台接口只需要 2 天，B 团队负责前端交互可能需要 5 天。如果只看需求个数，容量就失真了。

我们的应对是引入了 T-shirt Sizing 的跨团队通信机制。注意，这和故事点不同，T-shirt Sizing 只在跨团队协调时使用，不作为团队内部的规划工具。

具体做法：

• 每个需求在进入跨团队 Epic 时，由各相关团队用一个粗略的 T-shirt Size 标记自己负责的部分：XS（1-2天）、S（2-4天）、M（4-8天）、L（8-12天）、XL（12天以上，需要拆解）
• T-shirt Size 不是通过 Planning Poker 讨论出来的，而是每个团队的技术负责人根据历史相似需求的开发数据，30 秒内凭经验判断的
• 跨团队协调时只做“容量匹配”：A 团队说我们还能接一个 M 级的需求，B 团队说我们只能接一个 XS 的了

这个方法的核心区别在于：T-shirt Size 是“信息传递”而非“绩效度量”。它不进入任何效能报表，管理层看不到也不关心这个 Size。它的唯一用途是帮助多个团队在一分钟内确认“各方容量能不能对得上”。

只要一个指标不被用于绩效评估，它就不会被系统性博弈。这是我们从故事点的教训中提炼出的最深刻的原则。

七、代价与取舍：这样做你会失去什么

1. 你失去的第一个东西：向上汇报的“量化故事”

说一个很现实的问题。用故事点的时候，你给管理层汇报是有数字的：“我们这个季度交付了 520 个故事点，环比增长 8%。”数字清晰、曲线漂亮、PPT 好做。

砍掉故事点之后，你拿什么汇报？我们在内部实验的初期被问到这个问题，沉默了几秒钟。

后来我们想清楚了：用故事点汇报的“量化增长”，本质上是一个统计假象。因为故事点本身在通胀，你的 8% 增长里可能有一半是估算尺度变化带来的，另一半才是真实的生产力提升。

替代方案是用业务成果指标向上汇报：

• “本季度交付了 47 个关键客户需求，其中 62% 在承诺日期前完成”
• “高优先级需求的平均交付周期从 18 天缩短到 12 天”
• “客户 NPS 评分在最近两次调研中提升了 7 分，主要归因于 XXX 功能的及时上线”

但这些指标比“520 个故事点”更难获取、更难归因、更难在汇报时建立干净的因果关系。这是你选择这条路必须承受的代价。

我们的经验是：如果你所在的组织文化高度依赖量化指标来评价研发团队，那你需要在这个文化转变之前，先有足够的高层背书。不要试图从下往上推，这本质上是一场管理哲学层面的变革，需要自上而下的支持。

2. 你失去的第二个东西：新人的工作量参照系

故事点有一个容易被忽视的功能：它给新人团队提供了一个“工作规模”的共同参照。

当一个新人加入团队，听到“这个需求 5 个故事点”，虽然他不一定马上知道这代表了什么，但几次 Sprint 之后他就能建立自己的直觉：“大概 5 点的需求需要我花 2-3 天”。“5 点”成为团队共同语言的一部分。

砍掉故事点后，新人的这个参照系消失了。我们实验中发现，新加入团队的工程师在前两个 Sprint 中明显缺乏对任务规模的概念，出现过两次新人接了太多需求导致 Sprint 结束无法交付的情况。

我们的应对是：在 Onboarding 阶段引入了“典型需求日历”机制，新人前两周不直接参与 Sprint 任务领取，而是跟着一个 Mentor 经历两个 Sprint，记录每类典型需求的平均开发时长，建立自己的经验数据集。

这个方法更慢，但学习效果更扎实，新人不是在记忆一个抽象的故事点数字，而是在建立自己的判断力。

3. 你失去的第三个东西：Scrum 工具的原生支持

还有一个很实际的障碍：市面上大部分 Scrum 管理工具都是以故事点为核心设计的。Backlog 排序、燃尽图、Velocity 报表，都是基于故事点的。你一旦砍掉故事点，这些工具的原生报表就直接废了。

我们在 PingCode 内部走运，因为我们可以修改自己的产品，我们花了 6 周给 PingCode Project 开发了“优先级排序模式”的 Alpha 版本，支持决策卡片、优先票投票、需求级别容量规划、非故事点的 Sprint 进度可视化。

但如果你用的是 Jira、Trello 或其他固定模型的工具，你需要想清楚：砍掉故事点意味着你的报表体系需要一套完全不同的配置。我们的一些客户选择在工具中把“故事点”字段隐藏，然后用一个自定义优先级字段替代燃尽图，看的是“Sprint 需求完成率”而非“故事点燃尽比例”。

八、谁应该这么干，谁不应该

1. 适合砍掉故事点的团队特征

基于我们的实验数据和客户案例，以下特征的团队更适合尝试砍掉故事点：

• 团队规模在 15 人以上、有多个并行 Sprint：单人团队不需要故事点，但 3-5 人的小团队用故事点的博弈成本相对可控。规模越大，故事点异化的速度越快，砍掉的收益越明显。
• 需求变化频繁、业务不确定性高：市场变化快、客户需求经常调整的团队，故事点提供的“稳定性”本身就是伪命题，你精确估算的需求下个月可能完全变了。
• 有成熟的产品负责人和 Sprint Master：优先级排序对这两个角色的能力要求比故事点模式更高。产品负责人需要能讲清楚每个需求的价值判断，Sprint Master 需要能在决策对齐环节把控讨论质量。
• 高层认可“成果导向”而非“产出导向”：这是最关键的条件。如果组织仍然以“完成了多少点”来评价研发团队，你砍掉故事点就是自断手脚。

2. 不适合砍掉故事点的团队特征

同样基于我们的观察，以下情况的团队应该谨慎：

• 强依赖的项目型交付场景：如果你们的交付模式是固定范围、固定工期的项目制（而非产品制），故事点的估算价值会更高。因为在这种场景下，你对工作量的预测确实会影响资源配置和合同条款。
• 团队成员经验差异极大且缺乏导师机制：如果团队新人和资深工程师的比例超过 1:1，且没有成型的 Onboarding 机制，故事点作为新人参照系的价值会更高。
• 跨团队依赖极其复杂的系统架构：如果每做一步都需要 4-5 个团队的精密协作，故事点提供了跨团队的“工作量通用语”，虽然不精确但有。没有这个通用语，跨团队协调的沟通成本会急剧上升。
• 组织文化对不确定性容忍度低：这可能是最根本的制约因素。有些组织的管理 DNA 就是对不确定性的容忍度极低，必须要有数字、要有预测、要有对比。在这样的组织里强推优先级排序，你会死在文化冲突上。

九、实操路线图：如果你想这么干，从哪开始

1. 先跑一个“影子 Sprint”

不要一上来就在全团队砍掉故事点。我们推荐的起步方式是：选一个相对独立的子团队（8-12人），在不影响正式 Sprint 的前提下，跑一个“影子 Sprint”做完整的优先级排序实验。

影子 Sprint 的意思是：该团队仍然按照正常的故事点流程进行正式 Sprint 规划和交付，但同时要求在规划会上额外花 30 分钟完成一次优先级排序的“影子规划”。两个结果对比看：

• 正式 Sprint：按故事点规划出来的 Sprint Backlog
• 影子 Sprint：按优先级排序出来的 Sprint Backlog

比较两个 Backlog 的差异，哪些需求进了正式但没进影子？哪些进了影子但没进正式？原因是什么？

我们的经验是，第一次跑影子 Sprint 时，两个 Backlog 的重合度通常只有 60%-70%。那 30%-40% 的差异就是“故事点噪音”，一些其实不太重要的需求因为估点小、方便凑数，被塞进了 Sprint；而一些重要的需求因为估点大、不好安排，被推迟了。

2. 第二步：用 3 个 Sprint 完成过渡

影子 Sprint 验证了方向可行之后，我们建议用 3 个 Sprint 完成正式过渡：

Sprint 1：故事点和优先级并行。两个都做，故事点正常估，优先级正常排。Sprint 结束后重点观察：故事点估算和实际的偏差到底有多大？优先级排序对 Sprint 目标达成是否有正向影响？

Sprint 2：故事点只记录不使用。正常估算故事点，但 Sprint Backlog 的规划完全以优先级排序结果为准。故事点数据只留在后台作为对照。这个 Sprint 的目的是让团队逐步适应“优先级说了算”的感觉。

Sprint 3：完全砍掉故事点。规划会上不再出现故事点估算环节，全面运行此前设计的决策对齐机制。Sprint 结束后做一个完整的团队复盘：什么感觉更好？什么感觉更差？需要调什么？

3. 第三步：建立专属的效能面板

砍掉故事点之后不能留一个真空。我们建议在第三个 Sprint 开始之前就准备好替代的效能指标体系。

我们推荐的“优先级排序模式”的效能面板包含以下核心指标：

• Sprint 目标达成率（二进制：达成/未达成，目标是持续达到 80% 以上）
• P0/P1 需求交付率（高优先级需求的实际完成比例，目标是 85% 以上）
• 需求平均交付周期（从需求进入 Sprint Backlog 到验收通过的日历天数，目标是在团队可控范围内持续缩短）
• 备选池需求平均等待时间（P2/P3 需求在备选池里的滞留时长，这个指标防止低优先级需求被无限期推迟）
• 技术健康预算使用率（每个 Sprint 的 20% 技术容量是否被充分利用，目标接近 100%）

这个面板的核心设计原则是：只度量“结果”，不度量“中间产物”。故事点就是中间产物，优先级排序后的需求交付率才是结果。

十、总结：优先级排序不是技术方案，是文化选择

回到最初的那个问题：我们砍掉了故事点，用优先级排序，然后呢？

六个月的实验让我最深的体会是：砍掉故事点这件事本身，其实只占了整个变革 20% 的难度。真正难的 80% 是：如何在团队内部建立对“优先级”的一致理解；如何让技术债务在商业价值主导的排序中不被边缘化；如何让管理层接受“我们不再汇报故事点了”；如何让新人团队在没有故事点这个共同语言的情况下建立工作量直觉。

如果你只是把故事点从流程中去掉，然后在原位置插入一个“优先级排序工具”，你一定会失败。因为这不是一个工具替换的问题，这是从“度量产出”到“驱动成果”的范式转换。产出是你能数得清的东西，几个需求、几行代码、几个故事点。成果是你的用户和客户因为你的交付而发生了什么样的改变。

产出的度量简单直观，所以组织天然倾向于用它来评价团队。成果的度量复杂滞后，但它是唯一对业务有意义的度量。

选择优先级排序，本质上就是选择了一条更难的路：放弃对中间产物的精确度量幻想，直面业务成果的不确定性和归因困难。

这条路不适合所有团队。但如果你的团队正处在需求变化快、故事点异化严重、规划会议变成了数字游戏的阶段，那我可以告诉你：有人走过这条路了。它不是银弹，但它比继续在一个失效的度量体系里假装还有控制感，要清醒得多。

下一步行动建议：如果你读到了这里，我建议你做的第一件事不是立刻在团队里推行这个模式，而是做一次数据自检，调出你过去 6 个 Sprint 的数据，计算故事点估算和实际交付的偏差率。如果偏差率超过 25%，你可以把这篇文章发给你的 Sprint Master，然后在下一次回顾会上花 15 分钟讨论一个简单的问题：“我们对故事点的投入，值这个偏差率吗？”

有时候，一个好的问题比一个完美的方案更有力量。