下面是我對于 Scrum 的學習、了解及總結，參考了 Scrum 指南和一些書籍，并加入了自己的一些了解，希望對自己有用。
Scrum 是以經驗過程控制理論為依據，采用疊代、增量的方法來提高産品開發的可預見性并控制風險。Scrum 的三大支柱支撐起每個經驗過程控制的實作。
第一大支柱是高透明度
高透明度確定管理結果的人看得到那些影響結果的過程方面。這些過程方面不僅要透明，而且那些被觀察到的方面也必須被充分了解。這就是說，當某人檢驗某個過程并認為完成了某些任務時，這個完成必須等同于他們的完成定義。
第二大支柱是檢驗
開發過程中的各方面必須做到經常性的檢驗，以確定及時發現過程中的重大偏差。在确定檢驗頻率時，需要考慮到檢驗會引起所有過程發生變化。當規定的檢驗頻率超出了過程檢驗所能允許的程度，那麼就會出現問題。幸運的是，軟體開發并不會出現這種情況。另一個因素就是檢驗工作成果人員的技能水準和勤勉程度。
第三大支柱是适應
如果檢驗員經檢驗發現過程中的一個或多個方面不滿足可接受标準，并且最終産品是不合格的，那麼檢驗員就必須對過程或是材料進行調整。調整工作必須盡快實施以減少進一步的偏差。
Scrum 中有三個進行檢驗和适應的時刻： 每日例會是用來檢驗朝向 Sprint 目标的工作程序，調整以優化次日的工作價值。另外，Sprint 評審和計劃會議是用來檢驗朝向釋出目标的工作程序，調整以優化下一個Sprint 的價值。最後，Sprint 回顧會議是用來評審完成的 Sprint，并确定什麼樣的調整可以使下一 Sprint 的效率更高、結果更令人滿意和更易于工作。
Scrum 團隊的目标是提高靈活性和生産能力。
靈活價值觀：
個體與互動 重于 過程和工具
可用的軟體 重于 完備的文檔
客戶協作 重于 合同談判
響應變化 重于 遵循計劃
“靈活開發”一詞源自《靈活宣言》。
Scrum 角色(Scrum Roles)：
流程經理(Scrum Master)：ScrumMaster 負責確定 Scrum 團隊遵守 Scrum 價值、實踐和規則；幫助 Scrum 團隊和整個組織采用 Scrum；通過指導和引導，教授 Scrum 團隊更高效工作、生産出高品質的産品；幫助 Scrum 團隊了解并采用自組織和跨職能。
産品負責人(Product Owner)：産品負責人是管理産品待辦事項清單、確定團隊工作價值的唯一責任人。
團隊(Scrum Team)：開發人員組成的團隊負責在每個 Sprint 将産品待辦事項清單轉化成為潛在可傳遞的功能增量。
團隊的 Team Leader 就是 ScrumMaster。團隊的理想規模是7(±2)人。産品負責人和 ScrumMaster 這兩個角色不計入成員人數，除非他們也是“豬”。Scrum 團隊成員被稱為“豬”。産品負責人是産品待辦事項清單的“豬”。團隊是 Sprint 任務的“豬”。ScrumMaster 是 Scrum 過程的“豬”。其他人被稱為“雞”。“雞”沒有權利要求“豬”如何去開展工作。
“雞”和“豬”的比喻來自于以下的故事：
一隻雞對一頭豬說：“我們合夥開家飯店吧！”豬想了想，說：“那我們給這個飯店起什麼名字呢？”雞說：“雞蛋和火腿！”豬回答到：“那還是算了吧，你要做的隻是下幾隻雞蛋，我把命都搭上了！”
時間盒(Time-Box)：
| 釋出計劃會議(Release Planning Meeting) | |
| 目标 | 釋出計劃會議的目的是建立 Scrum 團隊與組織内的其他部門能夠了解和溝通的計劃和目标。 |
| 主持人 | 産品負責人 |
| 參與者 | ScrumMaster、團隊全體成員 |
| 時間 | 通常不超過組織建構傳統釋出計劃的15-20%時間 |
| 地點 | 會議室 |
| 準備 | 與 Sprint 計劃會議相同 |
| 成果 | 釋出目标 具有最高優先級的産品待辦事項清單 重大風險 釋出所包含的全部特性和功能 确立大緻傳遞日期和費用 |
| 主要内容 | 釋出計劃會議需要回答以下兩個問題：“我們如何以最佳方式将願景轉化為成功的産品？我們怎樣才能達到或甚至超越客戶的滿意度和投資回報？” 與 Sprint 計劃會議基本類似，隻是範圍不同，而估算也會比較粗略。 |
| 日程安排 | 沒有既定日程安排，主要看産品的實際情況而定。 |
| 其他 | 定義驗收标準時，可以根據重要性區分“必須釋出”、“應該釋出”和“可緩釋出”等不同等級。 關于時間估算，應該對最重要的條目進行時間估算，應該由團隊來做估算，估算隻是粗略估算不是承諾，不要花太多時間。機關為故事點，具體可以參看 Sprint 計劃會議部分說明。 關于生産率估算，可以參看 Sprint 計劃會議部分說明。确定重要性、釋出等級、時間估算、生産率估算後就可以排定釋出計劃，類似如下圖所示：  其中生産率估算為 45 個故事點，每個 Sprint 的時間估算合計不超過該生産率估算。最後可以增加一些時間緩沖，以避免糟糕的時間估算、未預期的問題和未預期的特性等造成影響。 關于調整釋出計劃，每個 Sprint 之後，我們都要看一下這個 Sprint 的實際生産率。如果實際生産率跟估算生産率差距很大，我們就會給下面的 Sprint 調整生産率，更新釋出計劃。如果這會給我們帶來麻煩，産品負責人就會跟客戶進行談判；或者檢查一下是否能夠在不違反合同的情況下調整範圍；或者他跟團隊一起找出一些方法，通過消除某些在 Sprint 中發現的嚴重障礙，提高生産率或是投入程度。 組合使用 Scrum 和極限程式設計(XP)會有顯著收獲，Scrum 注重的是管理群組織實踐，而 XP 關注的是實際的程式設計實踐，它們解決的是不同領域的問題，可以互為補充，相得益彰。與 XP 相關的有結對程式設計(Pair Programming)、測試驅動開發(TDD)、增量設計、持續內建、代碼集體所有權、充滿資訊的工作空間、代碼标準、可持續的開發速度/精力充沛的工作。 關于在 Sprint 中需要完成的非程式設計性任務的例子：搭建測試環境。明确需求。與營運部門讨論部署的操作細節。編寫部署文檔（版本說明，RFC，或任何在你們組織中要寫的東西）。和外界的資源進行聯系（例如 GUI 設計師）。改進建構腳本。将故事進一步拆分成任務。辨別出來自開發人員的核心問題，并幫助解決這些問題。 關于 Sprint 後回報的 Bug 的處理，可以在下一個 Sprint 中把“将舊功能産品化”配置設定高優先級。 |
| Sprint | |
| 目标 | 團隊将 Sprint 待辦事項清單轉化成為可傳遞的功能增量。 一個 Sprint 就是一個疊代，Sprint 是以時間盒限定的。在 Sprint 中，ScrumMaster 負責確定不出現任何影響 Sprint 目标的變化。 |
| 主持人 | ScrumMaster |
| 參與者 | 團隊全體成員 |
| 時間 | 2 周 ~ 4 周，一般 3 周比較适中 |
| 地點 | 團隊最好能夠在獨立房間中坐在一起工作，避免外界幹擾 |
| 準備 | Sprint 計劃會議結束後 |
| 成果 | 完成 Sprint 目标 産品增量 經驗積累 |
| 主要内容 | Sprint 計劃會議 開發工作 每日例會 Sprint 評審會議 Sprint 回顧會議 |
| 日程安排 | 周一 09:00 – 17:00 Sprint 計劃會議 平日 10:00 – 10:15 每日例會 周四 09:00 – 12:00 Sprint 評審會議 周四 14:00 – 16:15 Sprint 回顧會議 周五 實驗日 |
| 其他 | 關于實驗日，可以在兩個 Sprint 之間設定 1 天實驗日，讓大家可以放松一下，可以做任何他想做的事情，比如研習最新的工具和 API、準備認證、跟同僚讨論亂七八糟的事情、開發自己喜歡的項目，等等。這樣你就能得到自然的休息，開發團隊也能讓自己了解最前沿的知識。這也是一種能夠吸引員工的福利。例如安排周四進行 Sprint 評審會議和 Sprint 回顧會議，周五為實驗日，下周一進行下一輪的 Sprint 計劃會議。 如果團隊發現承諾的任務過多，可以和産品負責人溝通，以減小 Sprint 中標明的産品待辦事項清單範圍。如果團隊發現有富餘的時間，可以和産品負責人商議追加額外的産品待辦事項清單。 |
| Sprint 計劃會議(Sprint Planning Meeting) | |
| 目标 | Sprint 計劃會議制定疊代計劃。舉辦 Sprint 計劃會議，是為了讓團隊獲得足夠的資訊，能夠在幾個星期内不受幹擾地工作，也是為了讓産品負責人能對此有充分的信心。 |
| 主持人 | 産品負責人 |
| 參與者 | ScrumMaster、團隊全體成員 |
| 時間 | 3 周的 Sprint 對應 6 小時，在 Sprint 開始的時候 |
| 地點 | 會議室 |
| 準備 | 在 Sprint 計劃會議之前，要確定産品待辦事項清單的井然有序： 産品待辦事項清單必須存在。 隻能有一個産品待辦事項清單和一個産品負責人（對于一個産品而言）。 所有重要的 Backlog 條目都已經根據重要性被評過分，不同的重要程度對應不同的分數。 産品負責人應當了解每個故事的含義（通常故事都是由他來編寫的，但是有的時候其他人也會添加一些請求，産品負責人對它們劃分先後次序）。他不需要知道每個故事具體是如何實作的，但是他要知道為什麼這個故事會在這裡。 産品負責人之外的人也可以向産品 Backlog 中添加故事，但是他們不能說這個故事有多重要，這是産品負責人獨有的權利。他們也不能添加時間估算，這是開發團隊獨有的權利。 |
| 成果 | Sprint 目标 Sprint 示範時間、地點 經過團隊認可、要添加到這個 Sprint 中的故事清單 Sprint 中每個故事的估算值 Sprint 中每個故事的“如何示範” 生産率和資源計算，用作 Sprint 計劃的現實核查。包括團隊成員的名單、投入程度及每個人的承諾（不然就沒法計算生産率） 明确每日例會固定舉行的時間地點 把故事拆分成任務 |
| 主要内容 | 第一部分中決定 Sprint 需要做什麼。第二部分團隊研究在 Sprint 内如何将功能建構成産品增量。 每個故事都含有三個變量，它們兩兩之間都對彼此有着強烈依賴。範圍(Scope)和重要性(Importance)由産品負責人設定。估算(Estimate)由團隊設定。在 Sprint 計劃會議上，經過團隊和産品負責人面對面的對話，這三個變量會逐漸得到調整優化。 會議啟動以後，産品負責人一般會先概括一下希望在這個 Sprint 中達成的目标，還有他認為最重要的故事。接下來，團隊從最重要的故事開始逐一讨論每個故事，一一估算時間。在這個過程中，他們會針對範圍提出些重要問題：“‘删除使用者’這個故事，需不需要周遊這個使用者所有尚未執行的事務，把它們統統取消？”有時答複會讓他們感到驚訝，促使他們調整估算。 在某些情況下，團隊對故事做出的時間估算，跟産品負責人的想法不太一樣。這可能會讓他調整故事的重要性；或者修改故事的範圍，或者對故事進行分拆，導緻團隊重新估算，然後一連串諸如此類的後續反應。 關于品質，我們分為内部品質和外部品質。外部品質是系統使用者可以感覺的。運作緩慢、讓人迷糊的使用者界面就屬于外部品質低劣。内部品質一般指使用者看不到的要素，它們對系統的可維護性有深遠影響。可維護性包括系統設計的一緻性、測試覆寫率、代碼可讀性和重構等等。我把外部品質也看作範圍的一部分。産品負責人必須弄清楚内部品質是不可能讓步的，他一般都會處理好其他變量。 |
| 日程安排 | 09:00 – 17:00 （每小時休息 10 分鐘，中午休息 2 小時） 09:00 – 12:00 第一部分：做什麼 09:00 – 09:30 産品負責人對 Sprint 目标進行總體介紹，概括産品待辦事項清單。定下示範的時間、地點。 09:30 – 11:00 團隊估算時間，在必要的情況下拆分 Backlog 條目。産品負責人在必要時修改重要性評分。理清每個條目的含義。所有重要性高的 Backlog 條目都要填寫“如何示範”。 11:00 – 12:00 團隊選擇要放入 Sprint 中的故事。計算生産率，用作核查工作安排的基礎。 12:00 – 14:00 午餐、休息 14:00 – 17:00 第二部分：怎麼做 14:00 – 17:00 為每日例會安排固定的時間、地點（如果和上次不同的話）。把故事進一步拆分成任務。 |
| 其他 | 關于估算值，可以每人給定一些牌（包括：0,1/2,1,2,3,5,8,13,20,40,100,?,咖啡），每人均要對故事進行估算并同時亮牌，通過即時溝通逐漸讓團隊估算趨于一緻。 關于生産率，估算生産率(Estimated velocity) = 可用人天(Available man-days) * 投入程度(Focus factor)，根據曆史資料計算：投入程度 = 實際生産率(Actual velocity) / 可用人天，預設投入程度：70%。可用人天是所有團隊成員在本次 Sprint 中可以高效的、不受打擾的投入開發的天數總和。 關于技術故事，指的是需要完成但又不屬于可傳遞物的東西，跟任何故事都沒有直接關聯，不會給産品負責人帶來直接的價值的故事。例如：安裝持續建構伺服器、編寫系統設計概覽、重構 DAO 層、更新 Bug 跟蹤工具等。試着避免技術故事。努力找到一種方式，把技術故事變成可以衡量業務價值的普通故事。如果無法把技術故事轉變成普通故事，那就看看這項工作能不能當作另一個故事中的某個任務。如果以上二者都不管用，那就把它定義為一個技術故事，用另外一個單獨的清單來存放。産品負責人能看到它，但是不能編輯它。用“投入程度”和“預估生産率”這兩個參數來跟産品負責人協商，從 Sprint 裡撥出一些時間來完成這些技術故事。 |
| Sprint 評審會議(Sprint Review) | |
| 目标 | Sprint 末尾時要舉行 Sprint 評審會議，一個月的 Sprint 通常對應 4 小時時間盒的評審會議。評審會議又稱為示範會議，這是一個非正式會議，會議中進行功能示範，以促進下一步工作的互助與合作。 |
| 主持人 | 産品負責人 |
| 參與者 | ScrumMaster、團隊全體成員、相關幹系人（非必須）、組織其他人員（非必須） |
| 時間 | 3 周的 Sprint 對應 3 小時 |
| 地點 | 會議室 |
| 準備 | Sprint 中完成的故事 Sprint 中遇到的問題及如何解決 |
| 成果 | 示範會議的意義： 團隊的成果得到認可。他們會感覺很好。 其他人可以了解你的團隊在做些什麼。 示範可以吸引相關幹系人的注意，并得到重要回報。 示範是（或者說應該是）一種社會活動，不同的團隊可以在這裡互相交流，讨論各自的工作。這很有意義。 做示範會迫使團隊真正完成一些工作，進行釋出（即使是隻在測試環境中）。如果沒有示範，我們就會總是得到些 99% 完成的工作。有了示範以後，也許我們完成的事情會變少，但它們是真正完成的。這（在我們的案例中）比得到一堆貌似完成的工作要好得多，而且後者還會污染下一個 Sprint。 |
| 主要内容 | 産品負責人确定完成了哪些工作和剩餘哪些工作。 團隊讨論在 Sprint 中哪些工作進展順利、遇到了什麼問題、問題是如何解決的。 團隊示範完成的工作并答疑。 産品負責人和與會人員讨論産品待辦事項清單，并根據不同的速率計劃出可能的完成日期。 整個團體就哪些工作已經完成，同時這對下一步工作有何意義進行探讨。 Sprint 評審會議為接下來的 Sprint 計劃會議提供了寶貴的參考資訊。 |
| 日程安排 | 這是一個非正式會議，會議中進行功能示範，以促進下一步工作的互助與合作。下面的日程安排隻是一種模拟。 09:00 – 12:00 （每小時休息 10 分鐘） 09:00 – 11:00 團隊逐一示範每個已經完成的使用者故事。 11:00 – 11:30 團隊讨論遇到的問題和如何解決，并進行答疑。 11:30 – 12:00 産品負責人确定完成了哪些工作，并和與會人員讨論産品待辦事項清單。 |
| 其他 | Sprint 示範檢查清單： 確定清晰闡述了 Sprint 目标。如果在示範上有些人對産品一無所知，那就花上幾分鐘來進行描述。 不要花太多時間準備示範，尤其是不要做花裡胡哨的演講。把那些玩意兒扔一邊去，集中精力示範可以實際工作的代碼。 節奏要快，也就是說要把準備的精力放在保持示範的快節奏上，而不是讓它看上去好看。 讓示範關注于業務層次，不要管技術細節。注意力放在“我們做了什麼”，而不是“我們怎麼做的”。 可能的話，讓觀衆自己試一下産品。 不要示範一大堆細碎的 bug 修複和微不足道的特性。你可以提到一些，但是不要示範，因為它們通常會花很長時間，而且會分散大家的注意力，讓他們不能關注更加重要的故事。 |
| Sprint 回顧會議(Sprint Retrospective) | |
| 目标 | 旨在對前一個 Sprint 周期中的人、關系、過程和工具進行檢驗。檢驗應當确定并重點發展那些進展順利的，和那些如果采用不同方法可以取得更好效果的條目。 |
| 主持人 | ScrumMaster |
| 參與者 | 産品負責人、團隊全體成員、相關幹系人（非必須）、組織其他人員（非必須） |
| 時間 | 3 周的 Sprint 對應 2 小時 15 分鐘，一般是 1 ~ 3 小時，在 Sprint 評審會議結束之後和下個 Sprint 計劃會議之前。 |
| 地點 | 一個能夠在不受幹擾的地方。一般不會在團隊房間中進行回顧，因為這往往會分散大家的注意力。 |
| 準備 | 需要示範的内容 Sprint 中遇到的問題及解決辦法 Sprint 中做得好的地方 Sprint 中需要改進的地方及改進方法 |
| 成果 | 将要在下個 Sprint 中實作的有效改進方法。 哪些做法可以保持 哪些做法需要改進 如何改進的具體想法 我們怎樣才能在下個 Sprint 中做的更好 |
| 主要内容 | 可以指定某人當秘書，記錄會議内容。 ScrumMaster 向大家展示 Sprint 待辦事項清單，在團隊的幫助下對 Sprint 做總結。包括重要事件和決策等。 我們會輪流發言。每個人都有機會在不被人打斷的情況下講出自己的想法，他認為什麼是好的，哪些可以做的更好，哪些需要在下個 Sprint 中改變。 我們對預估生産率和實際生産率進行比較。如果差異比較大的話，我們會分析原因。 快結束的時候，ScrumMaster 對具體建議進行總結，得出下個 Sprint 需要改進的地方。 團隊通過頭腦風暴得出所有的想法，寫在即時貼上，然後用“圓點投票”來決定下一個 Sprint 會着重進行哪些改進。每個人都有三塊小磁鐵，投票決定下個 Sprint 所要采取措施的優先級。他們可以随意投票，也可以把全部三票投在一件事情上。 根據投票情況，他們選出了 5 項要重點進行的過程改進，在下一個回顧中，他們會跟蹤這些改進的執行情況。 |
| 日程安排 | 14:00 – 16:15 （每小時休息 10 分鐘） 14:00 – 14:30 ScrumMaster 在團隊的幫助下對 Sprint 做總結。 14:30 – 15:30 大家輪流發言，提出需要保持的做法、需要改進的做法和如何改進的想法。 15:30 – 16:00 大家讨論及投票選出下一個 Sprint 會着重進行哪些改進。 16:00 – 16:15 ScrumMaster 對具體建議進行總結，得出下個 Sprint 需要改進的地方。 |
| 其他 | 關于“知識橋梁”，有一個人會參加所有的 Sprint 回顧會議，充當知識橋梁。他需要服從一些重要規則： 他應當是一個很好的傾聽者。 如果回顧會議過于沉寂，他應該問一些簡單而目标明确的問題，以刺激團隊展開讨論。例如“如果時間可以倒流，從第一天重新開始這個 Sprint，那你覺得哪些事情會用其它方式來做？” 他應該自願花時間參加所有團隊的全部回顧。 他應該有一定的行政權力，如果出現一些團隊無法控制的改進建議，他可以幫助推進實施。 |
| 每日例會(Daily Scrum) | |
| 目标 | 團隊每天進行 15 分鐘的檢驗和适應的會議就稱為 Scrum 每日例會。 |
| 主持人 | ScrumMaster |
| 參與者 | 團隊全體成員 |
| 時間 | 15 分鐘，一般選擇大家都能接受的最早的時間。 |
| 地點 | 任務闆前 |
| 準備 | 已經完成的任務、準備進行的任務、工作中的障礙 |
| 成果 | 增加新任務 更新任務闆 更新 Sprint 待辦事項清單 更新 Sprint 燃盡圖 解決工作中的障礙 |
| 主要内容 | 每日例會在各個 Sprint 都是在同一時間，同一地點進行。會議上，每個團隊成員需要彙報以下三個問題： 1. 從上次會議到現在都完成了哪些工作； 2. 下次每日例會之前準備完成什麼； 3. 工作中遇到了哪些障礙。 |
| 日程安排 | 10:00 – 10:15 團隊成員輪流發言 |
| 其他 | 關于遲到，可以設定規則，無論任何理由（除了預先請假并獲得準許）遲到，每遲到 1 分鐘捐獻 1 元（上限可以設定 50 元）存入團隊基金，供團隊活動使用。 關于“我不知道今天幹什麼”，首先可以讓團隊成員過一遍任務闆，明确目标、故事、任務，發現需要做的事情。然後檢驗目标是否已經達成，如果已經達成可增加故事到 Sprint 中，如果未達成通常可以發現新任務。最後可以采用其他方法，例如下面的做法： 羞辱式做法：“如果你不知道怎麼幫助團隊，我建議你還是回家去，或者看書，或者怎麼都行。要不也可以找個地方坐下，等别人需要幫忙的時候你就過去。” 守舊式做法：簡單給他們配置設定個任務了事。 施加同僚壓力的做法：對他們說，“Joe，還有 Lisa，你們兩個可以放松點，我們會站在這裡慢慢等，直到你們找到幫助我們完成目标的事情為止。” 奴役式做法：對他們說，“你們今天可以給大夥兒幹幹雜活。倒咖啡、做按摩、清理垃圾、做午飯，一切一切大家今天讓你們做的事情。”你會驚訝的發現 Joe 和 Lisa 在霎那之間就找出了有用的技術任務 :o) 如果團隊成員不太重要，可以考慮調離團隊；如果團隊成員比較重要，可以考慮讓他與其他團隊成員結對。 |
工件(Artifact)：
| 産品待辦事項清單(Product Backlog) | |
| 用途 | 産品待辦事項清單列出團隊正在開發的産品需求。産品負責人負責産品待辦事項清單的内容、可用性和優先級。 |
| 所有者 | 産品負責人 |
| 讀者 | ScrumMaster、團隊全體成員、相關幹系人（非必須）、組織其他人員（非必須） |
| 時間 | Sprint 計劃會議後更新 |
| 主要内容 | 清單中的條目以使用者故事的形式展現。 産品負責人了解所有的使用者故事。 産品負責人隻需要關注業務目标，如何解決問題的應該是開發團隊。 産品待辦事項清單中包含産品開發和傳遞成功産品需要的所有條件和因素。表中列出了所有的特性、功能、技術、改進方法和故障修複等對未來釋出産品進行的改變。産品待辦事項清單條目包含描述、優先級和估算的特征。優先級是以風險、價值和必要性驅動的。 |
| 主要的故事字段： | |
| ID | 統一辨別符，就是個自增長的數字而已。以防重命名故事以後找不到它們。 |
| 名稱 Name | 簡短的、描述性的故事名。比如“檢視你自己的交易明細”。它必須要含義明确，這樣開發人員和産品負責人才能大緻明白我們說的是什麼東西，跟其他故事區分開。它一般由 2 到 10 個字組成。 |
| 重要性 Importance | 産品負責人評出一個數值，訓示這個故事有多重要。例如 10 或 150。分數越高越重要。 |
| 初始估算 Initial estimate | 團隊的初步估算，表示與其他故事相比，完成該故事所需的工作量。最小的機關是故事點(story point)，一般大緻相當于一個“理想的人天(man-day)”。 不需要保證這個估值絕對無誤（比如兩個故事點的故事就應該花兩天時間），而是要保證相對的正确性（即，兩個點的故事所花費的時間應該是四個點的故事所需的一半） 一般每個故事控制在 2~8 個故事點，太小會引發微觀管理，太大會導緻承諾不足或過度承諾，需要進行拆分。 |
| 如何做示範 How to demo | 它大略描述了這個故事應該如何在 Sprint 示範上進行示範，本質就是一個簡單的測試規範。“先這樣做，然後那樣做，就應該得到……的結果”。 |
| 注解 Notes | 相關資訊、解釋說明和對其它資料的引用等等。一般都非常簡短。 |
| 額外的故事字段： | |
| 類别 Track | 目前故事的大緻分類，例如“背景系統”或“優化”。這樣産品負責人就可以很容易選出所有的“優化”條目，把它們的級别都設得比較低。類似的操作執行起來都很友善。 |
| 元件 Components | 通常在 Excel 文檔中用“複選框”實作，例如“資料庫，伺服器，用戶端”。團隊或者産品負責人可以在這裡進行辨別，以明确哪些技術元件在這個故事的實作中會被包含進來。這種做法在多個 Scrum 團隊協作的時候很有用——比如一個背景系統團隊和一個用戶端團隊——他們很容易知道自己應當對哪些故事負責。 |
| 請求者 Requestor | 産品負責人可能需要記錄是哪個客戶或相關幹系人最先提出了這項需求，在後續開發過程中向他提供回報。 |
| Bug 跟蹤 ID Bug tracking ID | 如果你有個 Bug 跟蹤系統，那麼了解一下故事與 Bug 之間的直接聯系就會對你很有幫助。 |
釋出燃盡圖(Release Burndown)：釋出燃盡圖記錄了在一段時間内産品待辦事項清單的總剩餘估算工作量。估算工作量以 Scrum 團隊群組織決定的機關為标準，時間是以 Sprint 為機關。
| Sprint 待辦事項清單(Sprint Backlog) | |
| 用途 | Sprint 待辦事項清單包含團隊需要執行的任務，進而将産品待辦事項清單條目轉化成“完成”的增量。 |
| 所有者 | |
| 讀者 | |
| 時間 | Sprint 計劃會議之後，第一次每日例會之前建立完成 |
| 主要内容 | |
| 主要的故事字段： | |
| ID | 統一辨別符，就是個自增長的數字而已。以防重命名故事以後找不到它們。 |
| 名稱 Name | 簡短的、描述性的故事名。比如“檢視你自己的交易明細”。它必須要含義明确，這樣開發人員和産品負責人才能大緻明白我們說的是什麼東西，跟其他故事區分開。它一般由 2 到 10 個字組成。 |
| 重要性 Importance | 産品負責人評出一個數值，訓示這個故事有多重要。例如 10 或 150。分數越高越重要。 |
| 初始估算 Initial estimate | 團隊的初步估算，表示與其他故事相比，完成該故事所需的工作量。最小的機關是故事點(story point)，一般大緻相當于一個“理想的人天(man-day)”。 不需要保證這個估值絕對無誤（比如兩個故事點的故事就應該花兩天時間），而是要保證相對的正确性（即，兩個點的故事所花費的時間應該是四個點的故事所需的一半） 一般每個故事控制在 2~8 個故事點，太大的需要進行拆分。 |
| 如何做示範 How to demo | 它大略描述了這個故事應該如何在 Sprint 示範上進行示範，本質就是一個簡單的測試規範。“先這樣做，然後那樣做，就應該得到……的結果”。 |
| 注解 Notes | 相關資訊、解釋說明和對其它資料的引用等等。一般都非常簡短。 |
| 額外的故事字段： | |
| 類别 Track | 目前故事的大緻分類，例如“背景系統”或“優化”。這樣産品負責人就可以很容易選出所有的“優化”條目，把它們的級别都設得比較低。類似的操作執行起來都很友善。 |
| 元件 Components | 通常在 Excel 文檔中用“複選框”實作，例如“資料庫，伺服器，用戶端”。團隊或者産品負責人可以在這裡進行辨別，以明确哪些技術元件在這個故事的實作中會被包含進來。這種做法在多個 Scrum 團隊協作的時候很有用——比如一個背景系統團隊和一個用戶端團隊——他們很容易知道自己應當對哪些故事負責。 |
| 請求者 Requestor | 産品負責人可能需要記錄是哪個客戶或相關幹系人最先提出了這項需求，在後續開發過程中向他提供回報。 |
| Bug 跟蹤 ID Bug tracking ID | 如果你有個 Bug 跟蹤系統，那麼了解一下故事與 Bug 之間的直接聯系就會對你很有幫助。 |
Sprint 燃盡圖(Sprint Burndown)：Sprint 待辦事項清單燃盡圖展現的是目前 Sprint 内剩餘的 Sprint 待辦事項清單工作數量。建立該圖需要通過累計 Sprint 中每日待辦事項清單估算來确定剩餘工作量。
規則(Rule)：将 Scrum 的時間盒、角色和工件聯系起來。
完成(Done)：Scrum 的一個規則是關于每個 Sprint 目标的，即嚴格按照“完成”的定義開發潛在可傳遞的産品增量。Scrum 要求團隊在每個 Sprint 内建構産品功能的增量。這個增量必須是潛在可傳遞的，因為産品負責人可能會要求立即實作該功能。為了做到這一點，增量必須是最終産品完整的一部分，必須是“完成”的。每個增量都必須可以和前面所有增量累加起來，并且進行過徹底的測試，以保證所有的增量能相容工作。
參考：
Scrum 指南下載下傳位址：http://www.scrum.org/scrumguides/
Scrum 官方網站：http://www.scrum.org
硝煙中的 Scrum 和 XP 我們如何實施 Scrum
MSF for Agile Software Development 5.0 版