逐个冲刺做预测：用你自己的数据，而非凭空猜测
在世界被打乱一年半之后，许多团队都被问到同一个令人尴尬的问题：什么时候能做完？供应链依旧不可靠，半个团队还在厨房餐桌上办公，而那种凭一厢情愿就承诺一个固定日期的老习惯已经显得格外糟糕。Scrum 给出了更好的答案，而且它不需要水晶球，它需要的是你真正去使用团队早已在产生的数据。
Scrum 建立在经验主义之上：你根据观察到的事实做决策，而不是根据一开始的假设。预测不过是把这一原则应用到未来。与其宣布一个日期然后寄希望于运气，不如衡量团队在最近几个冲刺中真正完成了多少工作，再把这个速率向前推算，同时对其中的不确定性保持坦诚。
先衡量吞吐量，而非承诺
最有用的数字往往也最简单：团队逐个冲刺真正完成了多少个产品待办列表项？这就是吞吐量。如果团队估算得足够一致，你可以使用故事点，但直接统计完成的条目通常同样好用，还能省去许多争论。把最近八到十二个冲刺的真实数据拿出来。不要去平滑它，不要删掉那些糟糕的冲刺，也不要把「差不多完成」的条目算进去——「完成的定义」是非此即彼的，自有其道理。
只统计在该冲刺中达到「完成的定义」的条目。
采用一致的时间窗口——最近八到十二个冲刺既反映当下现实，又不至于追溯太久远的历史。
保留离散度：一个交付 4、9、6、3、8 的团队，正在告诉你一个单一平均值会掩盖的信息。
把数据变成一个区间，而非一个日期
一旦你有了逐个冲刺的记录，预测就成了算术加上谦逊。诚实的结果从来不是单一日期，而是一个附带置信水平的区间。
估量剩余工作量。 数一数为你所预测的目标还需要多少个产品待办列表项。对待办列表排序，使最重要的条目优先被纳入。
找到你切合实际的速率。 取最近几个冲刺的吞吐量。悲观的预测采用较慢的冲刺；乐观的预测采用较快的冲刺。
相除得到冲刺数量。 剩余条目除以吞吐量便得到所需冲刺数。同时用慢速率和快速率计算，就能得出一个诚实的「X 到 Y 个冲刺之间」的区间。
每个冲刺都重新预测。 每次冲刺评审都会带来新数据。那时就更新预测——一个从不变化的预测，是被无视了，而非被信任。
把不确定性当成优点，而非坦白
承受压力的干系人想要一个确切日期，而本能就是给他们一个，好显得果断。要抵住这种冲动。把预测表述为「最可能是六个冲刺，若集成风险落地最多可能到九个」，远比一个自信满满、却人人私下都知道是虚构的「3 月 24 日」更有用、也更可信。如果说疫情这几年教会了我们什么，那就是变异性是真实存在的，假装它不存在只会把失望往后推。把区间讲清楚，点明乐观一端背后的假设，让产品负责人在心里有数的情况下做出取舍。
一点提醒：经验式预测只有在你的冲刺是真正的冲刺时才奏效。如果「完成」一再拖延、工作不断越过冲刺边界、或团队总是被打断，那么你的吞吐量数据就是噪声，你的预测也会继承这份噪声。先把交付纪律理顺，预测自会随之而来。
建立起一种让干系人真正信任的预测习惯，靠的不仅是一张电子表格——还需要交付纪律和清晰的治理。XNM 的项目集与项目交付咨询 帮助团队把这两者都落到实处。