在任何專案開始時建立的計劃都不能保證會發生什麼。事實上，這只是一個時間點的猜測。很多事情會合謀使計劃失效，專案人員可能來或去，技術會比預期更好或更糟，使用者會改變主意，競爭對手可能會迫使我們做出不同或更快的反應，等等。敏捷團隊認為每一個這樣的變化都會帶來機會，並且需要更新計劃以更好地反映當前情況的現實。
在每一個新的迭代開始時，一個敏捷團隊整合在前面的迭代中獲得的所有新知識，並相應地進行調整。如果一個團隊學到了一些可能影響計劃準確性或價值的東西，他們就會調整計劃。計劃的準確性可能會受到團隊發現他們過度或低估了進展速度的影響。或者他們會發現，某種型別的工作比以前想象的要耗費更多的時間。
計劃的價值可能會因產品所有者對潛在使用者的需求所獲得的知識而改變。也許，根據從早期迭代中看到軟體的反饋，產品所有者已經瞭解到，使用者希望看到更多的一種特性，並且他們沒有像以前想象的那樣重視另一種特性。在這種情況下，計劃的價值可以通過將更多所需的特性移動到釋出中來增加，而犧牲了一些價值較低的特性。
通過在Scrum中檢查和採用來處理需求的變化
也許Scrum和Agile最重要的因素是對溝通，開放和透明的熱情。這些因素是我們在日常工作中使用敏捷和Scrum實踐所做的一切的基礎; 這就是為什麼我們重視合同談判中的客戶協作以及為什麼我們不害怕迴應變化，因為我們知道反饋非常重要。
敏捷方法只要求我們從錯誤中吸取教訓和/或找出改進的新方法。作為敏捷宣言的原則之一：
“團隊定期反思如何變得更有效，然後相應地調整和調整其行為。”
正是通過這種開放式溝通的呼籲，Scrum鼓勵我們在Sprint期間舉辦五項重要活動，旨在幫助我們高效，緊密地合作，以及提高我們的知識，並在未來變得更加有效。
這五個事件是：
- Sprint計劃 (Sprint Planning)
- 每日Scrum (Daily Scrum)
- Sprint評論 (Sprint Review)
- Sprint回顧 (Sprint Retrospective)
- 衝刺 (Sprint)
下面的摘要顯示了在各種Scrum事件中的檢查和調整。
所有這些對於他們自己的權利至關重要，正因為如此，我將在這裡簡要地研究每一個。
Sprint計劃 (Sprint Planning)
這是啟動每個Sprint的事件，也是產品負責人和開發團隊討論哪些產品待辦事項專案（PBI）將包含在Sprint中的地方。雖然產品負責人有權優先考慮每個PBI以確定是否可能包含在Sprint中，但我們鼓勵開發團隊在必要時做出迴應，提出問題並進行回擊。然後，開發團隊預測他們可以在Sprint中提供多少PBI，因為他們瞭解速度，資源以及可能影響其可用時間和資源的任何因素。
Sprint計劃會議的結果是獲得Sprint目標和Sprint Backlog，每個人都同意這是現實和可實現的。
每日Scrum (Daily Scrum)
Scrum尋求有效利用您的時間和資源，Daily Scrum活動也不例外。每日Scrum的時間限制為15分鐘。站起來不是強制性的。然而，許多團隊認為這是一種有用的技術，可以使會議保持簡短和重要。
每日Scrum為開發團隊提供了一個機會，可以檢查，評估實現Sprint目標的進度，並在接下來的24小時內稽核和規劃他們的活動。
Sprint評論 (Sprint Review)
從敏捷宣言再次看上述原則 - “定期，團隊反思如何變得更有效，然後相應地調整和調整其行為。”_這一原則本身就總結了我們接下來兩次會議背後的原因，Sprint回顧和Sprint回顧。
這兩項活動都在Sprint結束時舉行。敏捷方法的目標不是第一次讓所有東西“完美”，而是持續改進。這些事件有助於實現這一目標。
Sprint評審通常在Sprint的最後一天進行，讓您有機會向利益相關者（客戶，管理層以及任何其他被認為相關和感興趣的人）展示“完成”增量。除了展示Sprint期間產生的工作特徵外，您還可以獲得有用的反饋，這些反饋可以包含在產品Backlog中，可以幫助指導未來衝刺的工作。
Sprint回顧 (Sprint Retrospective)
Sprint的最後一次會議是Sprint Retrospective。這是Scrum團隊審查未來Sprint可以改進的內容以及他們應該如何做的事情。Scrum的精神要求無論Scrum團隊有多好，總會有機會改進，Sprint Retrospective給團隊一個專門的時間來識別，討論和計劃。整個Scrum團隊應該參與其中，包括開發團隊，Scrum Master和產品負責人。會議應該是一個協作努力，就像整個Scrum和敏捷過程一樣。
衝刺 (Sprint)
Sprint本身就是一個事件，它包含所有工作以及在開箱時間內發生的所有其他事件。
更多推薦的 scrum 文章
- Scrum的基本功 - 集合中英文版本 (Scrum事件)
- Scrum的基本功 - 集合中英文版本 (Scrum工件)
- Scrum的基本功 - 集合中英文版本 (角色和責任篇)
- Scrum的基本功 - 集合中英文版本 (基礎篇)
- 它為客戶提供了一個在開發週期早期看到軟體的機會，並提供反饋和輸入，以便能夠快速、輕鬆地進行更正。
- 工作軟體是一個很好的進度度量。從實際完成、測試和交付到使用者滿意程度的增量軟體功能方面衡量進展要準確和有效得多，而不是試圖衡量未完成的大型開發專案的完成百分比。