内容简介：如何看待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不一样,采用的是看板的思路，更加注重过程中流动和调整。
以上所述就是小编给大家介绍的《如何看待Scrum Sprint Backlog冻结和变化？》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
