如何看待Scrum Sprint Backlog冻结和变化？

最近常常碰到的一个问题是 如何看待和处理迭代中的backlog的变化？

Scrum对Sprint backlog范围在Sprint中坚持不变，这与瀑布里面冻结需求的做法较为接近。

这样的迭代待办事项的冻结，对外不能快速响应外部的变化；对内让团队吃自己的狗食，并且容易引起product owner与scrum master和团队对于迭代工作范围的矛盾，进而给scrum mastsr提出了非常高的软技能要求。

冻结待办事项并不是说sprint开始前define好的story在sprint开始后on hold，而是是指范围冻结，是指在planning meeting所选择的sprint backlog不变，可以对既有的条目细化，精化，但不能增加和减少。

早年间的csm培训，花费不少时间来讲沟通技巧，典型的句式是yes，but… 和 yes, and…, 不说no。

这是很不错的沟通小技巧。但其本质是有点虚伪的。

冻结Sprint backlog这样做是为了防止变更，使得Sprint相对容易成功。这样要求在迭代会议时 相关需求足够清晰
在sprint开始时的planning meeting上，sprint backlog是scrum team与Product Owner商量好的
但计划往往赶不上变化。 4周的迭代长度的话，很容易赶上变化，1周的迭代长度相对少变化，但也不是绝对没有变化。

最新的有些Scrum实施中，把Sprint分成两部分：1，一部分是承诺必须达成的，2，另外一部分是弹性部分。这是对硬性冻结Sprint Backlog灵活调整，被不少团队采用。

ScrumBan 在这方面的做法与Scrum不一样,采用的是看板的思路，更加注重过程中流动和调整。