在 sprint 迭代當中，由於很多不確定的因素，有什麼可行的 Scrum DeadLine 設定和管理方法？

01-15

對於Scrum的項目中，一些商業項目需要指定一個DeadLine，既然是估算肯定有誤差，在sprint迭代當中，由於很多不確定的因素，比如客戶的想法慢慢清晰，越來越細緻，就會導致加班甚至重來，很容易項目延期，我現在做的是：估算「注水」，天天盯著這些可變的因素，進行調整，有啥可行的

有些基本條件你沒有滿足

在sprint的一個迭代周期，往往是不允許出現大的需求蔓延和需求變更的，新增加的需求可以放到下一個迭代周期，而不是當前迭代。

為了達到上面這點，對sprint的輸入是有一定要去的，如果user story和迭代要實現的feature都沒有搞清楚，是不能進入sprint裡面的。sprint迭代的優先順序本身一個重要考慮就如輸入的需求的確定性和穩定度。sprint計劃也需要進行相應的估算，估算全體團隊確認，需要保證其一定的嚴謹性。否則又會演變為無計劃。

scrum裡面的計劃是根據嚴格的計劃，而不是無計劃。

研發團隊：在sprint計劃會議中，需求方挑選本期sprint要進行的story，也是一種承諾。一旦sprint開始，不允許方向性的需求變更，當然類似文案修改這樣的小改動是允許的。如果需求有較大變更，放入下一個sprint執行。

需求方：較大的需求變更，提前2-3個sprint就要提出構想，由開發團隊進行評估。而不是在一個sprint開展前才倉促進行。這對需求方有較高要求，要做到一定高度上的長期規劃，並且需求的方向性有自信。

估算注水也是預留buffer，任何開發中都會有變數。buffer則是對這些變數進行調節的最佳方式。當sprint進行較多後，可以逐漸量化出團隊的專註度和開發能力，從而更科學的進行估算。

在制定sprint plan的時候，不僅僅是開發團隊的事情，po也一定要參加，這個po，可以是產品經理，也可能就是你直接面對的客戶。

scrum其中一條：儘可能拉客戶參與到迭代中來，通過這種方式儘可能讓客戶自己了解解決他們一些需求所導致的成本。徹底地以客戶為導向所導致的風險任何方法框架都無法解決，因為命根掌握在別人手中，這時，溝通就變得非常重要。

做sprint plan的時候，列出risk極其mitigation，需求不明晰是個典型的不能再典型risk，attack這個risk的mitigation應該是盡量早的與客戶溝通細化需求，再增加上由此產生的開發時間。讓你的客戶明白，需求是可以改的，但是應盡量在項目早期，在中後期的需求變更當然也可以，但是需要合理的額外開發時間。

早期對可變因素進行風險分類

過程中保證獲得反饋的及時性和有效性

任務分解儘可能細

任務執行確保閉環

最後，注水是必須的