最近常常碰到的一個問題是 如何看待和處理迭代中的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冻结和变化？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。