## 建立故事的時機

1. 由Scrum Master和Product Ower來寫故事。敏捷雖然是要提高大家的積極度或參與度，但是故事建立並不需要每個成員都參與，如果都參與寫故事會造成故事風格不統一，對整體評估和說明反而不利。

2. 故事建立要提前。Scrum Master需要提前安排好下次迭代開發的故事，並把需求轉化為故事，產品需求文件和故事基本可以同時送到團隊開發成員。我們上次開發是，一起過需求，然後給大家需求分析時間，然後列故事，對故事進行評估。這樣就造成一點不好，Scrum Master和開發人員同時拿到需求，都需要時間分析，而Scrum Master建立故事的時候，大家是沒事幹的，這個時間至少需要半天。所以Scrum Master需要提前把下次迭代的故事列到backlog裡面，下次迭代直接選取優先順序高的故事開發，更有利也更合理。

## 如何建立故事

編寫好的故事，關注六大特徵 INVEST：獨立的 (Independent)，可討論的 (Negotiable)，對使用者或客戶有價值的 (Valuable to Purchasers or Users)，可估計的 (Estimatable)，小的 (Small)，可測試的(Testable)。我們開發中的經驗是更注重，小的，獨立的，可測試的。
* 大的故事一定要拆分，別超過5天，否則故事到Done的時間過長，也不利於控制。
* 獨立的，避免故事之間的相互依賴，如果過大，按第一條拆分。
* 可測試的，表示對使用者有價值的一個流程，而不是通過頁面來劃分，很容易陷入這種模式，一個或幾個設計介面組成一個故事，這種看是明確的東西，其實隱藏了需求關聯性，也容易在開發中容易造成功能遺漏，比方說頁面之間的關聯功能。故事描述格式可以寫作，作為使用者，需要什麼功能，以便做什麼事情。比方說，作為使用者需求登入功能進入後臺管理。

## 時間預估

撲克牌，每人根據自己情況得出一個天數
如果估算不一致，通過最多和最少估算人說出自己的估算方式，避免遺漏，也避免考慮過多
不需要把故事的需求細節瞭解的太細，而且不要把細節或實現方式放到估算會上，故事細節由使用者和開發人員討論得出。

預估是估算，不可能每個故事都特別準確，但最終的整體時間是可參考的

使用檔案故事做估算時的工作量包含 1. 需求分析/架構設計/編碼/測試/部署（至初驗款結帳），所包含範圍的工作量大約是純編碼期的兩倍略多 2. 需求模糊所需的討論/測試/返工/修改缺陷/響應客戶提出變更/乃至部署後提出的變更（在初驗結賬前），所包含的範圍大約是“一次完成”的1～N倍。 4. 由於有多個人參與專案，所以由分工造成的文件/交流/溝通時間/修改別人Bug/人員離職時閱讀別人的程式碼……等時間。 國內的20多個數據表明，若將團隊控制在2人，生產率就能達到業界水平的2倍。但很可惜，“2人團隊”一般需要至少一個業務和技術均過硬的高手參加，而除非一家公司1/2的人都具備這個素質，否則不可能全部變成2人團隊。 5. 人員儘管定編在此專案中，但需要參加其他日常會議/領導前來打攪/緊急缺陷的修復/閒聊/上網……一切最終實際上會被填報在日誌中的工時。某些時間看上去很不應該參與到生產率計算中（比如“閒聊/上網”），但因為永遠不會有人單獨填報“閒聊/上網”時間，所以它們實際上都被填報到日報中參加計算了；“領導前來打攪”的工作量，也不可能計算到其他專案中，所以也計算在人員所定編的專案中。 6. ……