如何看待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不一样,采用的是看板的思路,更加注重过程中流动和调整。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页