Scrum中的估算陷阱：一份本迭代就能用来规避它们的清单
估算是Scrum中被误用得最严重的实践之一。《Scrum指南》并未强制要求故事点、计划扑克或任何特定技术——它只是说开发者负责为工作定量，而产品负责人与开发者共同精炼产品待办列表，使条目达到就绪状态。然而团队却往往把估算变成压力、虚假精确和摩擦的来源。到了2021年，多数规划都在视频通话中进行，估算方式里那些悄无声息的扭曲变得更难被发觉。
下面这份清单，你可以在下一次迭代规划或精炼会议上使用。它不会让估算变得完美——没有什么能做到——但能让估算保持诚实而有用。
估算清单
以团队为单位估算，而非个人。 计划扑克之类技术的意义，在于把不同的假设摆到台面上。当声音最大的人或资深开发者一锤定音时，你就失去了那场让估算真正有价值的对话。
把估算当作相对值，而不是改头换面的工时。 故事点比较的是条目之间的工作量与复杂度。一旦有人宣称“一个点等于一天”，你就用更多步骤重建了工时估算，也丢掉了它的价值。
在规划之前精炼，而非在规划当中。 未经事先讨论就被拖进迭代规划的条目，只能靠猜。持续精炼意味着团队已经啃过那些大的未知。
凡是大到无法理清的，就拆分。 一个巨大的估算，是团队在告诉你他们并不理解这个条目。把它拆成足够小的片段，让不确定性变得可见、可讨论。
用速率来预测，绝不用来评判。 速率帮助团队规划一个迭代里能纳入多少工作。一旦它变成绩效指标，人们就会虚报估算，这个数字也就不再有任何意义。
学到新东西时就重新估算。 估算是你当时所知的一张快照。当新信息出现时，更新它，而不是去维护一个早已过时的猜测。
需要警惕的预警信号
估算从不改变，这通常意味着团队在倒推数字以迎合期望。
管理者把不同团队的点数速率拿来对比，仿佛它们是同一种货币。
为某个条目究竟是三还是五争论不休，而这点差距很少会影响决策。
产品负责人把估算往下压，这会污染开发者唯一能给出的诚实信号。
看待估算最健康的方式，是把它当成一场对话，而不是一个数字。得出“五”的那番讨论——揭示出一处隐藏的依赖、一项测试方面的顾虑、一条含糊的需求——通常比“五”本身更有价值。如果你的会议只产出数字却没有这番对话，那你衡量的不过是“同意往下走”，而非共同的理解。
从这份清单里挑两三条，在下一次会议上试用。你很可能会发现，目标从来都不是准确，而是拥有一个对工作理解到足以满怀信心地承诺迭代目标的团队。
如果你的团队想打磨规划、估算与交付的方式，XNM的项目群与项目交付咨询 可以帮你建立能在真实压力下站得住脚的敏捷实践。