真正能按时收尾的冲刺规划：两支团队，两种结局
《Scrum 指南》给冲刺规划设了三个要回答的主题：这个冲刺为什么有价值、能做什么、工作将如何完成。看上去够简单。然而，使用同一套框架的两支团队，冲刺收尾时却可能落在完全不同的地方——一支交出了可用的增量、达成了冲刺目标，另一支则带着一堆做了一半的工单滚入下一次。差别很少出在框架上，而在于团队如何使用规划这一事件。设想两支团队，各八人，都刚熬过供应频频出岔子、复工后半远程半坐班的 2022 年。
会溢出的那支团队
A 团队把规划当成往队列里塞活的仪式。这套模式很常见，也悄悄注定了他们每两周抱怨一次的溢出。
没有冲刺目标，只有一张清单。没有目标，承压时什么都砍不掉，因为每一项看起来都同等必须。
产品待办列表未经梳理就送来，于是规划时间被用来破译需求，而不是决定范围。
产能被无视。明明两人休假、一人有一半精力分给支持，团队却照搬上一个冲刺的条目数量。
「完成」含糊不清。没人确认完成到底指什么，于是测试和评审到很晚才被发现，被算作下一个冲刺的问题。
依赖项——供应商的一个零件、一项外部审批——是在冲刺中途才被注意到，而不是趁计划还可调整时就摆上台面。
A 团队整个冲刺都很忙，却照样没达标。他们把忙碌错当成进展，又因为没有目标，现实闯进来时也没有什么可以拒绝。
稳稳落地的那支团队
B 团队把规划当成一份打算兑现的预测。他们开的是同一个事件、用的是同一个小时，习惯却更利落。
先定下冲刺目标。 产品负责人带来一个单一而具体、增量应当达成的目标。目标成为决策筛子：凡是不服务于它的，都是可以延后的候选项。
按真实产能规划，而非上一个冲刺的条目数。 把休假、支持轮值、会议都减掉。开发者只挑他们真心相信能完成的，而且由他们来定——挑选权在他们，不在产品负责人。
提前梳理到刚刚好，而不是当场梳理。 得益于持续梳理，待办列表顶部的条目已经足够小、足够清晰、有了粗略估算；规划谈的是承诺，而非临场摸索。
为头几天拆出一份真正的计划。 团队把顶部条目拆成可以立刻动手的任务。他们不需要整个冲刺的每个细节，但头几天是具体的。
对每一项都套用「完成的定义」。 测试、评审、集成都包含在估算之内，而非事后才想起。一个条目只有在团队相信它能真正「完成」、而不只是写完代码时，才算被纳入。
当冲刺中途出岔子——零件迟到、依赖卡住——B 团队会和产品负责人对照冲刺目标重新协商范围，仍能交付有价值的东西。A 团队则只是把没做完的活往后挪，还美其名曰速率。框架完全一样，纪律却不一样。如果你的冲刺总是溢出，解药通常不是冲刺期间更拼命，而是规划出一份你真能担保的预测，并锚定在一个你愿意守护的目标上。
如果你的冲刺一再溢出，而你想要一份站得住脚的规划，XNM 的项目集与项目交付咨询 可以帮你的团队朝着目标规划、并把它交付出来。