别再猜交付日期：用你自己的实证数据来预测
Scrum 建立在经验主义之上：你检视实际发生了什么，并依据证据而非一厢情愿来调整。预测正是这一原则最直接受到检验之处。预测得好的团队，赢得了被信任去驾驭不确定性的资格；预测得差的团队，则会被微观管理。《Scrum 指南》刻意不规定具体方法，而这份自由被许多团队用错了。
在2022年初，伴随招聘人员流动、重返办公室的扰动以及供应驱动的依赖关系，承诺一个干净日期的诱惑很强，而打破这个承诺的代价很高。预测不是承诺；它是基于真实数据的概率性陈述。把这一区别弄清楚，其余便顺理成章。
预测在哪里出错
把故事点数当作时间单位。 点数估计的是相对工作量而非小时数，并会随团队学习而漂移。用固定换算率把点数变成日期，是在制造虚假的精确。吞吐量，即每个 Sprint 完成的条目数，是更干净的预测依据。
用单一平均值来预测。 说团队每个 Sprint 大约做十个条目，掩盖了巨大的波动。一个数字最多给你一个五五开的预测。要对日期说出任何诚实的话，你需要的是离散程度，而不只是中间值。
使用的历史数据太少。 建立在两三个 Sprint 上的预测会继承它们全部的噪声。使用最近若干 Sprint 的滚动窗口，既足以捕捉正常波动，又足够新近以反映当下的团队，而非一年前的团队。
忽视范围增长。 预测假设待办列表静止不动，但真实的待办列表会随工作的发现而增长。若不考虑条目被加入的速度，你就是在对着一个不断后退的目标做预测。
把日期当作承诺来汇报。 单一的硬日期招致失望。用带置信水平的区间来沟通，能设定诚实的预期，并在现实落在区间之内某处时保护团队的可信度。
一种务实的实证方法
先在最近的窗口期里——比如六到十个 Sprint——统计每个 Sprint 的吞吐量。看分布，而不只是均值。由此出发，最简单而诚实的预测就是一个区间：在慢的几周团队完成这么多条目，按惯常节奏这么多，在状态好的几周这么多。把这些速率与剩余的（且在增长的）待办列表对照，得出一个带置信带的大致完成日期，而非单一的点。
在动用点数之前，先用吞吐量以完成条目数来预测。
把结果表达为带置信度的区间，绝不用孤立的单一日期。
考虑待办列表的增长，而不只是今天看得见的工作。
每个 Sprint 随新数据到来刷新预测，并允许它变化。
若想要更丰富的建模，对你的吞吐量历史做蒙特卡洛模拟，可把同样的数据转化为概率。
这一切都不需要笨重的工具；一张记录每个 Sprint 完成条目数的电子表格就足以起步。关键在于这份纪律：从团队实际做过的事出发去预测，坦率地传达不确定性，并不懈地更新。这就是把经验主义应用于未来，也正是一个被人信任的团队与一个被人事事质疑的团队之间的分野。
如果你的团队在凭希望而非吞吐量做预测，干系人已不再相信那些日期，XNM 的项目群与项目交付咨询 可以帮你建立经得起推敲的预测。