轉自：http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-7
Scrum 使用固定的事件來產生規律性，以此來減少 Scrum 之外的其它會議的必要。所有事 件都是有時間盒限定的事件，也就是說每一個事件限制在最長的時間范圍內。一旦 Sprint 開始，它的持續時間是固定的，不能縮短或者延長。而其他事件則可以在該事件的目標達成之后可以立即終止，如此確保時間被適當地使用而不會造成過程中的浪費。
Sprint 除了本身作為一個事件以外，它還是其他所有事件的容器，在 Scrum中的每個事件都是用來進行檢視和適應的正式機會。這些事件都是被特別設計用來確保達成透明和檢視。如果 Sprint不能成功地包含這些事件中的任何一個事件，導致透明化的降低，同時也會喪失進行檢視與適應的機會。
事件一：Sprint
Sprint 是 Scrum 的核心，其長度(持續時間)為一個月或更短時間的限時，在這段時間內 構建一個“完成的”、可用的和潛在可發布的產品增量。在整個開發過程期間，Sprint 的長 度通常保持一致。前一個 Sprint 結束后，新的下一個 Sprint 緊接着立即開始。
Sprint由 Sprint計划會議、每日Scrum 站會、開發工作、 Sprint評審會議和 Sprint回顧會議構成。
在 Sprint 期間:
- 不能做出有害於 Sprint 目標的改變;
- 不能降低質量的目標;以及,
- 隨着對信息掌握的增加，產品負責人與開發團隊之間對范圍內要做的事可能會要澄清 和重新協商。
每個 Sprint 都可以被視為一個項目，為期不超過一個月。就如同項目一樣，Sprint 被用於 完成某些事情。每個 Sprint 都會定義要開發什么，還有一份設計過和靈活的計划用來指導 如何做這些事、工作內容和最終產品。
Sprint 的長度限制在一個月內。當 Sprint 的長度太長的話，對要構建什么的定義就有可能 會改變，復雜性也有可能會增加，同時風險也有可能會增加。Sprint 通過確保至少每月一 次對達成目標的進度進行檢視和適應，來實現可預測性。Sprint 同時也把風險限制在一個 月的成本上。
取消 Sprint
Sprint 可以在 Sprint 時間盒結束之前取消。只有產品負責人才有取消 Sprint 的權力，雖然 他或她做這樣的決定也可能受到來自利益攸關者、開發團隊或是 Scrum Master 的影響。
如果 Sprint 目標過時，那么 Sprint 就會被取消。比如公司的發展方向或者市場上或技術上 的狀況發生改變，這些變化都可能導致 Sprint 被取消。總的來說，如果某個 Sprint 對其所 在環境來說失去了價值和意義，那么它就應該被取消。然而，由於 Sprint 的時間都很短， 所以取消 Sprint 的意義不大。
當取消某個 Sprint 時，任何做完和“完成”的產品待辦列表項都需要評審。假如成果的任何 部分具有潛在可發布的話，產品負責人通常會接受這個成果。所有未完成的產品待辦列表 項都會被放回到產品待辦列表中，並重新估算。花在它們身上的工作會很快地貶值，所以 必須經常性地重估。
取消 Sprint 會消耗資源，因為每個人都必須重新集合在另一個 Sprint 計划會議來開始另一 個 Sprint 。取消 Sprint 通常會對 Scrum 團隊造成重創，這種情況非常罕見。
事件二：Sprint 計划會議
Sprint 中要做的工作在 Sprint 計划會議中來做計划。這份工作計划是由整個 Scrum 團隊共 同協作完成的。
Sprint 計划會議是限時的，以一個月的 Sprint 來說最多 8 小時為上限。對於較短的 Sprint， 會議時間通常會縮短。Scrum Master 要確保會議順利舉行，並且每個參會者都理解會議的 目的。 Scrum Master 要教導 Scrum 團隊遵守時間盒的規則。
Sprint 計划會議回答以下問題:
1. 接下來的 Sprint 交付的增量中要包含什么內容?
2. 要如何完成交付增量所需的工作?
話題一: 這次 Sprint 能做什么?
開發團隊預測在這次 Sprint 中要開發的功能。產品負責人講解 Sprint 的目標以及達成該目 標所需完成的產品待辦列表項。整個 Scrum 團隊協同工作來理解 Sprint 的工作。
Sprint 會議的輸入是產品待辦列表、最新的產品增量、開發團隊在這個 Sprint 中能力的預 測以及開發團隊的以往表現。開發團隊自己決定選擇產品待辦列表項的數量。只有開發團 隊可以評估接下來的 Sprint 可以完成什么工作。
在開發團隊預測完這個 Sprint 中可交付的產品待辦列表項之后，Scrum 團隊草擬一個 Sprint 目標。Sprint 目標是在這個 Sprint 通過實現產品待辦列表要達到的目的，同時它也為 開發團隊提供指引，使得開發團隊明確開發增量的目的。
話題二: 如何完成所選的工作?
在設定了 Sprint 目標並選出這個 Sprint 要完成的產品待辦列表項之后，開發團隊將決定如 何在 Sprint 中把這些功能構建成“完成”的產品增量。這個 Sprint 中所選出的產品待辦列表 項加上交付它們的計划稱之為 Sprint 待辦列表。
開發團隊通常從設計整個系統開始，到如何將產品待辦列表轉換成可工作的產品增量所需 要的工作。工作有不同的大小，或者不同的預估工作量。然而，在 Sprint 計划會議中，開 發團隊已經挑選出足夠量的工作，以此來預估他們在即將到來的 Sprint 中能夠完成。在 Sprint 計划會議的最后，開發團隊規划出在 Sprint 最初幾天內所要做的工作，通常以一天 或更少為一個單位。開發團隊自組織地領取 Sprint 待辦產品列表中的工作，領取工作在 Sprint 計划會議和 Sprint 期間按需進行。
產品負責人能夠幫助解釋清楚所選定的產品待辦列表項，並作出權衡。如果開發團隊認為 工作過多或過少，他們可以與產品負責人重新協商所選的產品待辦列表項。開發團隊也可 以邀請其他人員參加會議，以獲得技術或領域知識方面的建議。
在 Sprint 計划會議結束時，開發團隊應該能夠向產品負責人和 Scrum Master 解釋他們將如 何以自組織團隊的形式完成 Sprint 目標並開發出預期的產品增量。
Sprint目標
Sprint 目標是在當前 Sprint 通過實現產品待辦列表要達到的目的。它為開發團隊提供指 引，使得團隊明確為什么要構建增量。Sprint 目標在 Sprint 計划會議中確定。Sprint 目標為 開發團隊在 Sprint 中所實現的功能留有一定的彈性。所選定的產品待辦列表項會提供一個 連貫一致的功能，也即是 Sprint 目標。Sprint 目標可以是任何其他的連貫性來促使開發團 隊一起工作而不是分開獨自做。
開發團隊必須在工作中時刻謹記 Sprint 目標。為了達成 Sprint 目標，需要實現相應的功能 和實施所需的技術。如果所需工作和預期的不同，開發團隊需要與產品負責人溝通協商 Sprint 待辦列表的范圍。
事件三：每日Scrum站會
每日 Scrum 站會是一個以 15 分鍾為限的事件，它讓開發團隊同步開發活動，並為接下了
的 24 小時制定計划。這需要檢視上次每日站會以來的工作和預測下次每日站會之前所能 夠完成的工作。
每日 Scrum 站會在同一時間同一地點舉行，以便降低復雜性。在會議上，每一個開發團隊 成員都需要說明:
- 昨天，我為幫助開發團隊達成 Sprint 目標做了什么?
- 今天，我為幫助開發團隊達成 Sprint 目標准備做什么?
- 是否有任何障礙在阻礙我或開發團隊達成 Sprint 目標?
開發團隊借由每日 Scrum 站會來檢視完成 Sprint 目標的進度，並檢視完成 Sprint 待辦列表 的工作進度趨勢。每日 Scrum 站會優化了開發團隊達成 Sprint 目標的可能性。每天，開發 團隊應該知道如何以自組織團隊來協同工作以達成 Sprint 目標，並在 Sprint 結束時開發出 預期中的增量。開發團隊或者開發團隊成員通常會在每日 Scrum 站會后立即聚到一起進行 更詳細的討論，或者為 Sprint 中剩余的工作進行調整或重新計划。
Scrum Master 確保開發團隊每日站會如期舉行，但開發團隊自己負責召開會議。Scrum Master 教導開發團隊將每日 Scrum 會議時間控制在 15 分鍾內。
Scrum Master 強制執行每日 Scrum 站會規則——只有開發團隊成員才能參加。
每日 Scrum 站會增進交流溝通、減少其他會議、發現開發過程中需要移除的障礙、突顯並
促進快速地做決策、提高開發團隊的認知程度。這是一個進行檢視與適應的關鍵會議。
事件四：Sprint 評審會議
Sprint 評審會議在 Sprint 快結束時舉行 ，用以檢視所交付的產品增量並按需調整產品待辦 列表。在 Sprint 評審會議中，Scrum 團隊和利益攸關者協同討論在這次 Sprint 中所完成的 工作。根據完成情況和 Sprint 期間產品待辦列表的變化，所有參會人員協同討論接下來可 能要做的事情來優化價值。這是一個非正式會議，並不是一個進度匯報會議，演示增量的 目的是為了獲取反饋並促進合作。
對於長度為一個月的 Sprint 來說，評審會議的限時為 4 小時。對於較短的 Sprint 來說，會 議的時間會有所縮短。Scrum Master 要確保會議舉行，並且每個參會者都明白會議的目 的。Scrum Master 教導大家遵守時間盒的規則。
Sprint 評審會議包含以下內容:
- 產品負責人邀請 Scrum 團隊和主要的利益攸關者參加會議;
- 產品負責人說明哪些產品待辦列表項已經“完成”和哪些沒有“完成”;
- 開發團隊討論在 Sprint 期間哪些工作做的很好，遭遇到什么問題以及問題是如何解決 的;
- 開發團隊演示“完成”的工作並解答關於所交付增量的問題;
- 產品負責人討論當前的產品待辦列表的情況。他/她根據到目前為止的進度來預測可能的完成日期(如果有需要的話);
- 參會的所有人就下一步的工作進行探討，這樣， Sprint 評審會議就能夠為接下了的Sprint 計划會議提供有價值的輸入信息;
- 評審市場或潛在的產品使用方式所帶來的接下來要做的最有價值的東西的改變;同時，
- 為下個預期產品版本的發布評審時間表、預算、潛力和市場。
Sprint 評審會議的結果是一份修訂后的產品待辦列表，闡明很可能進入下個 Sprint 的產品 待辦列表項。產品待辦列表也有可能為了迎接新的機會而進行全局性地調整。
事件五：Sprint 回顧會議
Sprint 回顧會議是 Scrum 團隊檢視自身並創建下一個 Sprint 改進計划的機會。
Sprint 回顧會議發生在 Sprint 評審會議結束之后，下個 Sprint 計划會議之前。對於長度為 一個月的 Sprint 來說，會議的限時為 3 小時。對於較短的 Sprint 來說，會議時間通常會縮 短。Scrum Master 要確保會議舉行，並且每個參會者都明白會議的目的。Scrum Master 教 導大家遵守時間盒的規則。Scrum Master 作為 Scrum 過程的責任者，作為團隊的一員參加 該會議。
Sprint 回顧會議的目的在於:
- 檢視前一個 Sprint 中關於人、關系、過程和工具的情況如何;
- 找出並加以排序做得好的和潛在需要改進的主要方面;同時,
- 制定改進 Scrum 團隊工作方式的計划。
Scrum Master 鼓勵 Scrum 團隊在 Scrum 的過程框架內改進開發過程和實踐，使得他們能在 下個 Sprint 中更高效更愉快。在每個 Sprint 回顧會議中，Scrum 團隊通過適當地調整“完 成”的定義的方式來計划提高產品質量。
在 Sprint 回顧會議結束時，Scrum 團隊應該明確接下來的 Sprint 中需要實施的改進。在下 一個 Sprint 中實施這些改進是基於 Scrum 團隊對自身的檢視而做出的適當調整。雖然改進 可以在任何時間執行，Sprint 回顧會議提供了一個專注於檢視和適應的正式機會。